Pratiquer le BDD avec des tests d'intégration - ai-je aussi besoin de tests unitaires?

Question

À l'heure actuelle, mon processus de développement des flux comme ceci:

1. Je décris le comportement attendu comme un test d'intégration à l'aide à l'aide Webrat
2. Je Recopiez le code Ruby on Rails pour fournir ce comportement, en passant donc le test
3. Je Refactor, assurant que les tests passent encore à la fin du processus
4. j'écrire le prochain test d'intégration

Il me semble que par DEFI nition, mes tests d'intégration testent chaque modèle, contrôleur et vue que je peux créer. En réalité, est-ce que je rate quelque chose en n'écrivant pas des tests unitaires aussi?

Answer 1

Avez-vous des tâches de rake? Code capistrano personnalisé? Méthodes Cron? Une API? Monkeypatches? Qu'en est-il de l'intégration d'applications flex ou iPhone? Un coureur d'emploi?

Dans une application Rails classique, il y a beaucoup de code qui n'est pas utilisé par l'interface utilisateur HTML. Donc non, à moins que votre application ne soit incroyablement simple, les tests webrat ne seront pas suffisants.

Answer 2

Les tests d'intégration sont utiles pour vérifier que les différentes parties du code sont bien intégrées. Ils peuvent impliquer toutes les couches et couvrir tout le code mais ... lorsqu'un test d'intégration échoue, vous dira-t-il où se trouve le bogue? Je peux me tromper mais je ne le pense pas. Cela vous dira simplement qu'il y a un problème quelque part. D'un autre côté, quand un vrai test unitaire (écrit à l'aide de mocks ou de stubs) échoue, vous savez exactement dans quelle unité se situe le problème (c'est le but du test unitaire, vérifier qu'une unité implémente le comportement attendu) . En d'autres termes, les tests unitaires et les tests d'intégration sont utiles, mais ils ont des objectifs différents.

Answer 3

Je suis plutôt sympathique à votre point de vue ici. J'aime Concombre et J'aime RSpec - et je les utilise tous les deux, mais pas toujours sur le même code. Par exemple, j'écris rarement des exemples RSpec pour les contrôleurs Rails ces jours-ci, et je n'écris presque jamais les spécifications de vue. La plupart de mes contrôleurs sont très similaires et ne s'écartent pas beaucoup du modèle de contrôleur "stock" - qui est déjà bien testé par les tests unitaires de Rails. Vérifier à nouveau le même comportement ne gagne pas grand-chose pour le temps qu'il faut et les tracas de se moquer de tous les modèles. Avec le concombre au niveau de l'intégration, je peux passer cette moquerie et obtenir la vérification essentielle que je recherche. La plupart du temps, les tests de vue sont traités de manière beaucoup plus transparente dans le concombre. (Ensuite, je devrais voir "foo" et ainsi de suite.)

Mais cela ne veut pas dire que je n'utilise pas beaucoup RSpec dans Rails. Je l'utilise pour les endroits où vit ma logique: les modèles, les filtres de contrôleur, et les aides de vue. J'ai également un couple de projets qui sont presque tous logique métier, par exemple. bibliothèques ou adaptateurs d'API sur des interfaces tierces complexes. Pour ceux que je me trouve habituellement en utilisant RSpec exclusivement et en sautant le concombre.

En heuristique, je vous suggère que vous fortement envisager d'écrire un test unitaire tout moment l'une des questions suivantes peut répondre par « oui »:

• est le code que je vous écris plus que trivialement compliqué?
• Est-ce que ce code existe principalement pour donner des réponses à d'autres codes?
• Ce code existe-t-il que je refaçonne (qui n'a pas encore de test unitaire)?
• Ai-je trouvé un bogue dans ce code? (Si c'est le cas, écrivez un test unitaire avant de le réparer pour qu'il ne se faufile plus jamais.)
• Dois-je penser pendant plus de dix secondes à la façon la plus élégante d'implémenter ce code?
• Est-ce que mon picotement Spidey Sense?

Si aucune de ce qui précède est vrai, alors peut-être vous pouvez vous contenter de faire juste des tests d'intégration. Encore une fois, il y a beaucoup de cas où c'est raisonnable. Mais si vous rencontrez des problèmes plus tard, soyez prêt à payer le prix - et ce prix devrait inclure l'écriture de tests unitaires à tout moment si elles semblent nécessaires.