RSpec vs Cucumber (histoires RSpec) [fermé]

Quand dois-je utiliser les spécifications pour l'application Rails et quand Cucumber (anciennement rspec-stories)? Je sais comment fonctionnent et utilisent activement les spécifications, bien sûr. Mais il est toujours étrange d'utiliser du concombre. Mon point de vue actuel à 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 tout le système est censé fonctionner.

Mais que faire si je fais 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 concombre alors?

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. Premièrement, parce que la forme de l'histoire est très spécifique, elle aide à concentrer l'articulation du propriétaire du produit sur les fonctionnalités qu'il souhaite créer. C'est le «jeton pour une conversation» des histoires, et cela serait précieux que nous les implémentions ou non dans le code. Deuxièmement, lorsque le processus fonctionne suffisamment bien pour que nous ayons des histoires complètes avant de commencer à écrire la fonctionnalité (plus un idéal pour lequel nous nous efforçons qu'une réalité quotidienne), vos critères d'acceptation sont clairement définis et vous savez exactement quoi et comment beaucoup à 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 à conduire le développement des modèles et des contrôleurs, et les histoires ont tendance à conduire le développement des vues (nous avons tendance à ne pas écrire de rspec pour nos vues) et fournissent un bon test de l'application dans son ensemble à partir 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 profitez de webrat , écrire Cucumber peut être rapide et indolore pour une grande partie de vos fonctionnalités de base.

Pensez-y comme un cycle:

Écrivez votre fonction concombre, puis, tout en développant les pièces pour cette fonction, écrivez des 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é soit acceptée, puis écrivez votre prochaine fonctionnalité.

Je pense 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 entraîne pour vous. J'ai beaucoup écrit sur le sujet dans Pourquoi s'embêter avec des tests de concombre?

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

Comme le décrit Abie, il s'agit presque d'une liste d'exigences que l'application doit satisfaire, et est très utile pour la communication avec votre client, en plus d'être directement testable.

De nos jours, vous pouvez utiliser rspec avec Capybara et Selenium Webdriver et éviter d'avoir à créer et à maintenir tous les analyseurs d'histoires de Cucumber. Voici ce que je recommanderais:

1. Écrivez 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 comprend une nouvelle description et un bloc pour chaque scénario
4. Ensuite, j'implémenterais 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 voudrais TDD sur les contrôleurs et les modèles.
5. 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
6. répéter

Une chose à noter, cependant, est que les tests de contrôleur et d'intégration ont des chevauchements qui peuvent ne pas être nécessaires, vous devez donc utiliser votre meilleur jugement pour ne pas perdre votre temps.

De plus, une fois que vous avez trouvé votre groove, vous trouverez qu'il est plus agréable de le développer en utilisant BDD, jusque-là, ne vous sentez pas coupable si vous ne vous sentez pas comme si vous le faites parfaitement et n'y pensez pas trop. Vous ferez très bien!

Mais que faire si je fais 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 concombre alors?

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 interrompu 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 - elles fonctionnent simplement à un niveau d'abstraction plus élevé.