Je suis en train de mettre en place une application rails et je viens de finir de faire des tests unitaires et mon ami m'a dit que apparemment les appareils ne sont plus cool et que les gens utilisent maintenant RSpec ou shoulda. Je me demandais quels sont les avantages réels d'utiliser ces autres boîtes à outils. Toute information est appréciée.Pourquoi devrais-je utiliser RSpec ou shoulda avec Rails?
-fREW
RSpec et les cadres similaires sont des outils conçus pour faciliter le développement piloté par le comportement. Ils ne sont pas seulement une manière plus jolie d'écrire des tests, bien qu'ils aident à cela.
Il y a beaucoup d'informations sur les BDD ici: http://behaviour-driven.org/ Et wikipedia: http://en.wikipedia.org/wiki/Behavior_Driven_Development
Il y a trop d'avantages à la liste ici, donc je vous recommande la navigation de ce site un peu.
RSpec est beaucoup plus puissant, car il est beaucoup plus facile à lire et écrire des tests dans. Il est également très élégant lors de l'utilisation des simulacres et des talons, un concept qui deviendra extrêmement utile une fois que vous commencez à les utiliser dans tes tests. Essayez-le dans une application de test simple (NON RAILS!) Et vous verrez à quel point vos spécifications sont élégantes par rapport aux tests standard équivalents.
Personnellement, je préfère Shoulda à RSpec. Je trouve que Shoulda a moins de syntaxe magique que RSpec. Mon problème avec RSpec est que oui, il est très lisible quand je le lis à haute voix, mais quand j'arrive à l'écrire, hmmmm, je ne suis jamais sûr comment une affirmation donnée devrait être écrite. Prag Dave explains the problem better than me. Il a également likes Shoulda et a quelques exemples.
Il y a deux choses différentes:
La première chose est ce cadre à utiliser pour écrire des tests/spécifications. Ici vous pouvez choisir entre Test :: Unit, RSpec, Shoulda et ainsi de suite. Le choix est de savoir si vous voulez faire TDD traditionnel (Test :: Unit) ou si vous préférez les manières alternatives de penser au comportement spécifié par les développeurs comme David Chemlinsky (RSpec et dans une certaine mesure Shoulda).
La deuxième chose est de savoir comment gérer les données de test. Il existe des appareils Rails et des alternatives avec d'autres objectifs tels que the FixtureReplacement plugin. Avant les appareils Rails 2.0, il y avait des problèmes pratiques importants et bien documentés. Beaucoup de problèmes pratiques ont été corrigés dans Rails 2.0. Cependant, les appareils peuvent entraîner un couplage de test par inadvertance et certaines des solutions de rechange tentent d'éviter cela.
Consultez le document The Great Test Framework Dance-off de Josh Susser pour une comparaison des frameworks de test Ruby populaires.
Si vous construisez une application volumineuse et que vous n'avez pas une équipe capable d'écrire du code découplé qui peut être testé avec des tests de boîte noire et qui est prêt à utiliser/déboguer beaucoup de mocks & talons, ne descendez pas la route de l'usine. Où que vous lisiez sur la façon dont les usines impressionnantes sont, vous verrez une petite mise en garde sur la façon dont les usines pourraient ne pas être réalisables dans une grande application, car ils sont un peu plus lent que les appareils.
Mais "un peu plus lent" est vraiment plus lent.
Les usines ne sont pas significativement plus faciles à coder que les appareils qui utilisent des étiquettes pour les ID, à condition que vous conserviez les appareils organisés. Et dans certains cas, les usines sont plus difficiles à déboguer.Ce soir, j'ai converti une seule usine en fixtures, et le temps d'exécution du fichier de test qui l'a utilisée est passé de 65 secondes à 15 secondes, même si seulement 15% des tests de ce fichier test utilisent cette usine.
Si vous utilisez minitest, vous pouvez exécuter vos tests dans un ordre aléatoire; cela révélera rapidement tout couplage de données entre les tests. (pas sûr si rspec a l'option de randomiser l'ordre de test)
Test :: L'unité est bonne pour les petites applications. Mais il y a beaucoup d'avantages à utiliser des frameworks de test comme Shoulda ou RSpec, e. g. contextes !!
Je ne vois pas Shoulda et RSpec dans une relation-ou-. J'utilise Shoulda comme substitut à RSpec quand il s'agit de tests à simple assertion. J'aime vraiment les one-liners de Shoulda, mais écrire des matchers est beaucoup plus facile dans RSpec. Donc, mon conseil est d'utiliser les différents outils de test là où ils conviennent le mieux.
Vous pouvez utiliser un cadre de test comme le concombre qui est encore plus rapide que RSpec.
Je suis totalement d'accord avec le webmat. J'ai vraiment du mal à comprendre la syntaxe de RSpec parce qu'elle a tellement de sucre syntaxique. Il transforme les phrases ordinaires en code, mais alors vous avez compris ce qu'il est censé faire! La courbe est raide et je suis paresseux. – srboisvert
J'avais l'habitude d'être un peu méfiant de la syntaxe sucrée, mais après avoir lu http://rdoc.info/gems/rspec-expectations/2.4.0/RSpec/Matchers, je n'ai en fait aucun problème à écrire mes assertions avec La syntaxe de RSpec. (Peut-être que la documentation s'est simplement améliorée dans la période 2.5y depuis votre réponse. ^^) En fait, j'aime beaucoup mieux les attentes de RSpec que les affirmations de Test :: Unit (et cela sans se soucier de la "lisibilité anglaise" -)fonctionnalité). –