RSpec: Quelle est la différence entre une fonctionnalité et une spécification de demande?


113

Quelle est la différence conceptuelle entre Rspec de specs de caractéristiques et spécifications de demande ?

À partir de la documentation sur les spécifications des fonctionnalités:

Les spécifications de fonctionnalités sont des tests de haut niveau destinés à exercer des tranches de fonctionnalités via une application. Ils doivent piloter l'application uniquement via son interface externe, généralement des pages Web.

Et pour les spécifications de demande:

Les spécifications de demande fournissent un wrapper fin autour des tests d'intégration de Rails et sont conçues pour piloter le comportement à travers la pile complète, y compris le routage (fourni par Rails) et sans stubbing (c'est à vous de décider). Avec les spécifications de demande, vous pouvez:

  • spécifier une seule demande
  • spécifier plusieurs demandes sur plusieurs contrôleurs
  • spécifier plusieurs demandes sur plusieurs sessions

Je sais que les spécifications de fonctionnalités utilisent Capybara et les spécifications de demande ne le font pas. Mais cela ne mérite guère des concepts différents.

Réponses:


147

La différence conceptuelle est que vous testez généralement une user story et que toutes les interactions doivent être gérées via l'interface utilisateur. C'est là qu'intervient Capybara. Une spécification de requête teste toujours le comportement de votre application et n'a pas l'attente de lisibilité qu'un test d'acceptation aurait. Ainsi, la fonctionnalité est là pour la syntaxe améliorée pour les tests d'acceptation.

Les différences techniques incluent les spécifications de demande enveloppant les tests d'intégration Rails, contrairement aux spécifications de fonctionnalités. Cela signifie qu'avec les spécifications de requête, vous pouvez utiliser les méthodes get, post, put, delete et assert contre réponse. Avec les spécifications des fonctionnalités, vous devez conduire toutes les interactions via le navigateur et utiliser des méthodes telles que visiter et affirmer sur la page.

Je vous recommande de lire feature_spec.feature dans le code source rspec-rails sur github. J'espère que ça aide.


2
Alors recommanderiez-vous d'utiliser à la fois les spécifications de fonctionnalité et de demande, ou l'une ou l'autre est-elle suffisante? (Être nouveau à TDD ...)
robertwbradford

2
J'utilise les deux, @robertwbradford. J'utilise des spécifications de fonctionnalités pour conduire mon extérieur dans les tests - tester l'expérience utilisateur, puis développer la fonctionnalité à l'aide de tests unitaires. J'utilise des spécifications de demande pour tester les réponses - par exemple, dans une session_spec, je peux avoir un "GET /login"bloc de description avec des attentes dans des itblocs tels que expect(response.status).to eq(200)et expect(response).to render_template(:new), ou dans un describe "POST /sessions", un context "with valid credentials"bloc, avec expect(response).to redirect_to(user)etfollow_redirect!; expect(response.body).to include("Signed in")
Richard Jordan

5
Et utilisez-vous également les spécifications du contrôleur? Il semble qu'il y ait un peu de duplication entre ce que vous testez dans les spécifications de demande et ce qui est normalement testé dans les spécifications du contrôleur.
Ernesto

5
Cela dit, l'article lié ci-dessus décrit clairement les différences. Utilisez les spécifications de demande pour tester via l'API, utilisez les spécifications de fonctionnalités pour tester via le frontend.
Damien Roche

2
@RichardJordan: Une question: dans les spécifications des fonctionnalités, recommanderiez-vous d'utiliser des chemins Rails (c'est-à-dire visit users_path) ou des chaînes codées en dur ( visit '/users') ?. Personnellement, je préfère ne pas utiliser les composants internes de l'application dans ce type de spécifications.
tokland
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.