RSpec vs Cucumber (histoires de RSpec)

Question

Quand dois-je utiliser les specs pour une application Rails et quand Cucumber (anciennement rspec-stories) ? Je sais comment les deux fonctionnent et j'utilise activement les specs, bien sûr. Mais cela me fait toujours bizarre d'utiliser Cucumber. Mon opinion actuelle à ce sujet est qu'il est pratique d'utiliser Cucumber lorsque vous implémentez une application pour le client et que vous ne comprenez pas encore comment l'ensemble du système est censé fonctionner.

Mais que faire si je réalise mon propre projet ? La plupart du temps, je sais comment les parties du système interagissent. Tout ce que j'ai à faire est d'écrire un tas de tests unitaires. Quelles sont les situations possibles où j'aurais besoin de Cucumber alors ?

Et, deuxième question correspondante : dois-je écrire des spécifications si j'écris des histoires Cucumber ? Ne s'agirait-il pas d'un double test de la même chose ?

Answer 1

Si vous ne l'avez pas encore fait, vous pouvez consulter l'excellent article de Dan North, Qu'y a-t-il dans une histoire ? comme point de départ.

Nous avons deux utilisations principales des histoires de concombre. Tout d'abord, parce que la forme de l'histoire est très spécifique, elle aide le propriétaire du produit à se concentrer sur l'articulation des fonctionnalités qu'il veut construire. Il s'agit de l'utilisation des histoires en tant que "jeton pour une conversation", et elle serait précieuse, que nous implémentions ou non les histoires dans le code. Deuxièmement, lorsque le processus fonctionne suffisamment bien pour que nous ayons des histoires complètes avant nous commençons à rédiger la fonctionnalité (qui est plus un idéal à atteindre qu'une réalité quotidienne), vos critères d'acceptation sont clairement définis et vous savez exactement ce qu'il faut construire et en quelle quantité.

Dans notre travail sur Rails, les histoires Cucumber ne remplacent pas les tests unitaires rspec. Les deux vont de pair. En pratique, les tests unitaires tendent à diriger le développement des modèles et des contrôleurs, et les histoires tendent à diriger le développement des vues (nous avons tendance à ne pas écrire rspec pour nos vues) et à fournir un bon test de l'application dans son ensemble du point de vue de l'utilisateur.

Si vous travaillez en solo, l'aspect communication n'est peut-être pas très intéressant pour vous, mais les tests d'intégration que vous obtenez de Cucumber peuvent l'être. Si vous tirez parti de webrat Avec Cucumber, l'écriture de Cucumber peut être rapide et sans douleur pour une grande partie de vos fonctionnalités de base.

Answer 2

Pensez-y comme à un cycle :

Rédigez votre fonctionnalité Cucumber, puis, tout en développant les éléments de cette fonctionnalité, rédigez les spécifications pour compléter les composants individuels. Continuez à compléter les spécifications jusqu'à ce que vous ayez écrit suffisamment de fonctionnalités pour que la fonctionnalité soit acceptée, puis écrivez la fonctionnalité suivante.

Answer 3

À mon avis, c'est une mauvaise idée d'utiliser Cucumber dans la plupart des situations en raison des coûts de productivité que sa syntaxe vous impose. J'ai beaucoup écrit sur le sujet dans Pourquoi s'embêter avec les tests sur les concombres ?

Answer 4

Une histoire Cucumber est plus une description du problème global que votre application résout, plutôt que de savoir si des bouts de code individuels fonctionnent (c'est-à-dire des tests unitaires).

Comme le décrit Abie, il s'agit presque d'une liste d'exigences auxquelles l'application doit répondre, ce qui est très utile pour la communication avec votre client, tout en étant directement testable.

Answer 5

Aujourd'hui, vous pouvez utiliser rspec avec Capybara et Selenium Webdriver et éviter de devoir construire et maintenir tous les analyseurs d'histoires de Cucumber. Voici ce que je recommande :

1. Rédigez votre histoire
2. En utilisant RSpec, je créerais un test d'intégration ex : spec/integrations/socks_rspec.rb
3. Ensuite, je créerais un test d'intégration qui inclut un nouveau bloc describe and it pour chaque scénario.
4. Ensuite, je mettrais en œuvre la fonctionnalité minimale requise pour obtenir le test d'intégration et, tout en allant plus loin (dans les contrôleurs et les modèles, etc.), je ferais du TDD sur les contrôleurs et les modèles.
5. En remontant, votre test d'intégration devrait passer et vous pouvez continuer à ajouter des étapes au test d'intégration.
6. répéter

Une chose à noter, cependant, est que les tests du contrôleur et de l'intégration se chevauchent et peuvent ne pas être nécessaires. Vous devez donc utiliser votre meilleur jugement pour ne pas perdre votre temps.

En outre, une fois que vous aurez trouvé votre rythme, vous trouverez qu'il est plus agréable de se développer en utilisant le BDD. En attendant, ne vous sentez pas coupable si vous n'avez pas l'impression de le faire parfaitement et n'y pensez pas trop. Vous vous en sortirez très bien !