BDD avec concombre et rspec - quand est-ce redondant?

Question

Rails/outil version spécifique d': Quelle est l'ampleur des tests unitaires?

Maintenant, actuellement, j'écris:

• Dispositifs de concombre (tests d'intégration) - ces de test sur le HTML/JS qui est retourné par notre application, mais parfois aussi des tests d'autres choses, comme les appels vers les services de tiers.
• RSpec contrôleur de tests (tests fonctionnels), à l'origine uniquement si les contrôleurs ont tout sens logique, mais maintenant de plus en plus.
• RSpec modèle de tests (tests unitaires)

Parfois, cela est tout à fait nécessaire; il est nécessaire de tester le comportement du modèle qui n'est pas totalement évident ou visible à l'utilisateur final. Lorsque les modèles sont complexes, ils devraient certainement être testé. Mais d'autres fois, il me semble que les tests sont redondantes. Par exemple, avez-vous une méthode de test foo si elle n'est appelée que par bar, et bar est testé? Que faire si bar est une simple méthode d'aide sur un modèle qui est utilisé par et facilement vérifiables dans un Concombre fonctionnalité? Avez-vous de tester la méthode dans rspec ainsi que le Concombre? Je me trouve en difficulté avec cela, comme écrit plus de tests prennent du temps et la maintenance de plusieurs "versions" de ce qu'est effectivement le même comportement, ce qui rend le maintien de la suite de test plus beaucoup de temps, ce qui rend les changements de plus en plus onéreux.

En bref, ne vous croyez qu'il y a un temps lorsque vous écrivez uniquement des dispositifs de Concombre est-elle suffisante? Ou faut-il toujours d'essai à tous les niveaux? Si vous pensez qu'il existe une zone grise, quel est votre seuil de "ce besoin d'une fonctionnelle/test de l'unité." Concrètement, que faites-vous actuellement, et pourquoi (ou pourquoi pas) pensez-vous que c'est suffisant?

---

EDIT: Voici un exemple de ce que pourrait être "test exagéré." Certes, j'ai été capable d'écrire ce assez rapidement, mais il est complètement hypothétique.

Answer 1

Bonne question, j'ai abordé récemment, tout en travaillant sur une application Rails, également à l'aide de Concombre/RSpec. J'essaie de tester autant que possible à tous les niveaux, cependant, j'ai aussi constaté que la base de code grandit, j'ai parfois l'impression que je vais me répéter inutilement.

À l'aide de "outside-in" essais, mon processus est généralement quelque chose comme: Concombre Scénario -> Contrôleur de Spec -> Modèle de Spec. De plus en plus et je me retrouve à sauter sur le contrôleur spécifications comme le concombre scénarios couvrent une grande partie de leur fonctionnalité. J'ai l'habitude de revenir en arrière et ajouter le contrôleur spécifications, mais il peut se sentir comme un peu une corvée.

Une étape je prends régulièrement est de courir rcov sur ma dispositifs de concombre avec rake cucumber:rcov et de regarder pour des lacunes dans la couverture. Ce sont des zones de la code que j'ai assurez-vous de mettre l'accent sur ce qu'ils ont une protection décente, que ce soit de l'unité ou des tests d'intégration.

Je crois que les modèles/libs devrait être de l'unité testée à grande échelle, juste au large de la chauve-souris, comme c'est le métier de base de la logique. Il a besoin de travailler dans l'isolement, à l'extérieur de la normale web processus demande/réponse. Par exemple, si je suis en interaction avec mon application par le biais de la console Rails, je suis en train de travailler directement avec la logique métier et je veux l'assurance que les méthodes que j'appelle de mes modèles/classes sont bien testés.

À la fin de la journée, chaque application est différente et je pense que c'est vers le bas pour le développeur(s) afin de déterminer combien de couverture de test devrait être consacrée aux différentes parties de la base de code et de trouver le bon équilibre afin que votre suite de tests n'est pas le marais vous vers le bas en tant que votre application se développe.

Voici un article intéressant j'ai creusé de mes favoris qui mérite d'être lu: http://webmozarts.com/2010/03/15/why-not-to-want-100-code-coverage/

Answer 2

Rails a bien testé le code, alors j'aimerais éviter de ré-analyse des trucs qui sont couverts dans ces étapes.

Par exemple, sauf si il est de coutume de code, il est inutile de tester les résultats des validations à l'unité et fonctionnel. J'avais tester le niveau d'intégration bien. Dispositifs de concombre loi sur les spécifications de votre projet, il est bon de préciser que vous avez besoin d'une validation pour x et y, même si la mise en œuvre est une simple déclaration d'une ligne dans le modèle.

Answer 3

D'habitude vous ne voulez pas avoir à la fois le Concombre histoires et RSpec contrôleur specs/tests d'intégration. Choisissez-en un (en général, le Concombre est le meilleur choix, sauf pour certains cas particuliers). Ensuite, utilisez RSpec pour vos modèles, et c'est tout ce dont vous avez besoin.

Answer 4

Je l'ai tester un modèle complexe/lib méthodes avec rspec puis l'essentiel de la logique métier dans le web avec le concombre, donc je suis sûr que les principales caractéristiques du web sera à 100%, puis si j'ai eu plus de temps et de ressources que je test tout le reste.

Answer 5

Il est plus facile d'écrire de simples spécifications des méthodes simples. Son beaucoup plus facile que d'écrire cukes.

Si vous gardez vos méthodes simples et de garder vos spécifications simple - par le test de la logique à l'intérieur de cette méthode, vous allez trouver de la joie dans les tests unitaires.

Si tout est redondant son concombre tests. Si vous avez bien testé les modèles et les lib de votre logiciel devrait fonctionner.