RSpec vs Cucumber (histoires RSpec)
Quand devrais-je utiliser des spécifications pour Rails application et quand Cucumber (anciens rspec-stories)? Je sais comment les deux fonctionnent et utilisent activement les spécifications, bien sûr. Mais cela fait toujours bizarre d’utiliser Cucumber. Mon La vue 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.
Et si je fais mon propre projet? La plupart du temps, je sais comment les parties du système interagissent. Tout ce que je dois faire est d'écrire un tas de tests unitaires. Quelles sont les situations possibles où j'aurais alors besoin de concombre?
Et, comme deuxième question correspondante: dois-je écrire des spécifications si j'écris des histoires de concombre? Ne serait-ce pas un double test de la même chose?
Si vous ne l'avez pas déjà fait, vous voudrez peut-être consulter l'excellent article de Dan North, What's in a Story? comme point de départ.
Nous avons deux utilisations principales pour les histoires de concombre. Tout d'abord, parce que la forme de l'histoire est très spécifique, elle permet de concentrer l'articulation par le propriétaire du produit des fonctionnalités qu'il souhaite construire. Il s'agit de l'utilisation "symbolique d'une conversation" des histoires, et serait utile que nous ayons ou non implémenté 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 à écrire la fonctionnalité (plus un idéal que nous recherchons qu'un quotidien réalité), vous avez clairement défini vos critères d'acceptation et vous savez exactement quoi et combien construire.
Dans notre travail Rails, les histoires de concombre ne se substituent pas aux tests unitaires rspec. Les deux vont de pair. En pratique, les tests unitaires ont tendance à stimuler le développement des modèles et des contrôleurs, et les histoires ont tendance à stimuler le développement des vues (nous n'avons pas tendance à é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 peut ne pas être intéressant pour vous, mais les tests d'intégration que vous obtenez de Cucumber peuvent l'être. Si vous profitez de webrat , écrire Cucumber peut être rapide et indolore pour une grande partie de vos fonctionnalités de base.
Considérez-le comme un cycle:
Écrivez votre fonction Concombre, puis pendant le développement des pièces pour cette fonction, écrivez les spécifications pour compléter les composants individuels. Continuez à remplir les spécifications jusqu'à ce que vous ayez écrit suffisamment de fonctionnalités pour que la fonctionnalité passe, puis écrivez votre prochaine fonctionnalité.
Mon opinion est que c'est une mauvaise idée d'utiliser Cucumber dans la plupart des situations en raison des coûts de productivité que sa syntaxe implique pour vous. J'ai beaucoup écrit sur le sujet dans Pourquoi s'embêter avec les tests de concombre?
Une histoire de concombre est plus une description du problème global que votre application résout, plutôt que si des bits de code individuels fonctionnent (c'est-à-dire des tests unitaires).
Comme Abie le décrit, il s'agit presque d'une liste d'exigences auxquelles l'application doit répondre, et est très utile pour la communication avec votre client, tout en étant directement testable.
De nos jours, vous pouvez utiliser rspec avec Capybara et Selenium Webdriver et éviter d'avoir à construire et à maintenir tous les analyseurs d'histoire de Cucumber. Voici ce que je recommanderais:
- Écrivez votre histoire
- En utilisant RSpec, je créerais un test d'intégration ex: spec/integrations/socks_rspec.rb
- Ensuite, je créerais un test d'intégration qui comprend une nouvelle description et un bloc pour chaque scénario
- Ensuite, je mettrais en œuvre les fonctionnalités minimales requises pour obtenir le test d'intégration et tout en remontant plus loin (dans les contrôleurs et les modèles, etc.), je TDD sur les contrôleurs et les modèles.
- Au fur et à mesure que vous revenez, votre test d'intégration devrait réussir et vous pouvez continuer à ajouter des étapes au test d'intégration.
- répéter
Une chose à noter, cependant, est que le contrôleur et les tests d'intégration se chevauchent, ce qui peut ne pas être nécessaire, vous devez donc faire preuve de votre meilleur jugement afin de ne pas perdre votre temps.
De plus, une fois que vous trouverez votre groove, vous trouverez le plus agréable de développer en utilisant BDD, jusque-là, ne vous sentez pas coupable si vous ne vous sentez pas comme si vous le faisiez parfaitement et ne le pensiez pas trop. Vous ferez bien!
Et si je fais mon propre projet? La plupart du temps, je sais comment les parties du système interagissent. Tout ce que je dois faire est d'écrire un tas de tests unitaires. Quelles sont les situations possibles où j'aurais alors besoin de concombre?
Vous avez toujours besoin de concombre. Vous en avez besoin pour documenter la façon dont vous voyez le système fonctionner, et vous en avez besoin pour vous assurer que vous n'avez pas cassé les fonctionnalités lorsque vous changez les choses.
En d'autres termes, vous avez besoin d'histoires de concombre pour les mêmes raisons que vous avez besoin de tests unitaires - ils fonctionnent simplement à un niveau d'abstraction plus élevé.