Il semble qu'il y a deux approches totalement différentes à des tests, et je voudrais citer deux d'entre eux.
Le truc, c'est que ces opinions ont été exprimées il y a 5 ans (2007), et je suis intéressé, ce qui a changé depuis lors, et qui dois-je aller.
La théorie est que les tests sont censés être agnostique de la la mise en œuvre. Ce qui conduit à moins cassants tests et fait des tests le résultat (ou le comportement).
Avec RSpec, j'ai envie de l'approche commune de complètement se moquant de votre des modèles pour tester vos contrôleurs finit de vous forcer à regarder de trop dans la mise en œuvre de votre contrôleur.
Cela, en soi, n'est pas trop mauvais, mais le problème est qu'il est trop pairs dans le contrôleur de dicter la façon dont le modèle est utilisé. Pourquoi est-il importe si mon contrôleur des appels Chose.de nouveau? Que faire si mon contrôleur décide prendre la Chose.créer! et de sauvetage de la route? Que faire si mon modèle est doté d'une spécial de l'initialiseur de la méthode, comme Chose.build_with_foo? Mon spec pour le comportement ne doit pas échouer si je change la mise en œuvre.
Ce problème est encore pire quand vous avez imbriqué des ressources et sont la création de plusieurs modèles par le contrôleur. Certains de mes méthodes de configuration de la fin jusqu'à 15 ou plus de lignes de long et TRÈS fragile.
RSpec a l'intention d'isoler complètement de votre contrôleur logique à partir de vos modèles, qui sonne bien en théorie, mais presque va à l'encontre de la grain pour une pile intégrée comme des Rails. Surtout si vous pratiquez le maigre contrôleur/modèle de graisse de la discipline, le montant de la logique du contrôleur devient très faible, et la configuration devient énorme.
Qu'est donc un BDD-wannabe faire? Un pas en arrière, le comportement que j' bien envie de la tester n'est pas que mon contrôleur des appels Chose.de nouveau, mais que, compte tenu des paramètres X, il crée une chose nouvelle et redirige vers elle.
David Chelimsky:
Il est tout au sujet de faire des compromis.
Le fait que l'AR choisit l'héritage plutôt que de la délégation, nous met en un test de bind – nous devons être couplé à la base de données OU de nous devons être plus intime avec la mise en œuvre. Nous acceptons ce choix de conception parce que nous profiter de tous les bienfaits de l'expressivité et SÈCHE-ness.
Dans aux prises avec le dilemme, j'ai choisi des tests plus rapides au prix de un peu plus fragile. Vous avez le choix de moins cassants tests au coût de courir un peu plus lent. C'est un compromis de toute façon.
Dans la pratique, j'exécute les tests des centaines, si pas des milliers de fois, jour (j'utilise de l'autotest et de prendre très granulaire étapes) et si je change d' Utilisation de la "nouvelle" ou "créer" presque jamais. Aussi en raison de granulés étapes, de nouveaux les modèles qui apparaissent sont très volatils au premier abord. Le valid_thing_attrs approche réduit la douleur de cette un peu, mais cela signifie toujours que chaque nouveau champ obligatoire signifie que je dois changer valid_thing_attrs.
Mais si votre approche est de travailler pour vous dans la pratique, puis sa bonne! Dans fait, je voudrais vous recommandons fortement de publier un plugin avec des générateurs qui produisent de la exemples de la façon dont vous les aimez. Je suis sûr que beaucoup de personnes bénéficieront de cette.
Par curiosité, combien de fois utilisez-vous des objets fantaisie dans vos tests/specs? Peut-être que je suis en train de faire quelque chose de mal, mais je trouve sévèrement limiter. Depuis le passage à rSpec plus d'un mois, j'ai fait ce qu'ils recommandent dans les docs où le contrôleur et la vue de couches ne frappez pas la base de données et les modèles sont complètement moqué out. Cela vous donne un bon boost de vitesse et rend certaines choses plus facile, mais je trouve les inconvénients de le faire l'emportent de loin sur les avantages. Depuis en utilisant des objets fantaisie, mes specs ont transformé en un entretien cauchemar. Spécifications sont destinés à tester le comportement, pas la mise en œuvre. Je n'ai pas de soins si une méthode a été appelée, je veux juste m'assurer que le résultat obtenu est correcte. Parce que les moqueries fait spécifications pointilleux sur la la mise en œuvre, il rend simple refactorings (qui ne changent pas la le comportement) impossible de le faire sans avoir à constamment revenir en arrière et "fixer" les spécifications. Je suis beaucoup d'opinions sur ce qu'est une spec/essais doivent le couvercle. Un test ne devrait pause lors de l'application des pauses. C'est l'un la raison pourquoi je n'ai guère de test de la couche de la vue, car je le trouve trop rigide. Cela conduit souvent à des tests de rupture sans l'application de rupture lors de l' en changeant peu de choses dans la vue. Je suis la recherche le même problème avec des simulacres. En plus de tout cela, je viens de réaliser aujourd'hui que se moquant/stubbing une méthode de classe (parfois) autour de bâtons entre les spécifications. Spécifications devraient être autonome et n'est pas influencée par d'autres spécifications. Ce que les pauses la règle et conduit à la délicate bugs. Qu'ai-je appris de tout cela? Être attention lorsque vous utilisez les moqueries. Stubbing n'est pas aussi mauvais, mais il a encore certaines des mêmes questions.
J'ai pris depuis quelques heures et enlevé presque tous se moque de mes spécifications. J'ai aussi intégré le contrôleur et la vue des specs à une utilisation "integrate_views" dans le contrôleur spec. Je suis également le chargement de tous les luminaires pour chaque contrôleur de spec donc, il y a des données de test pour remplir les points de vue. Le résultat final? Mes specs sont plus court, plus simple, plus cohérente, moins rigide, et ils permettent de tester l'ensemble de la pile (modèle, vue, contrôleur), donc pas de bugs, que vous pouvez glisser à travers les mailles du filet. Je suis pas dire que c'est la "bonne" façon pour tout le monde. Si votre projet nécessite un très stricte spec cas, alors c'est peut-être pas pour vous, mais dans mon cas c'est les mondes mieux que ce que j'avais avant d'utiliser des simulacres. J'ai encore pensez stubbing est une bonne solution en quelques endroits, donc je suis encore en train de faire qu'.
