web-dev-qa-db-fra.com

Comment se lancer sur TDD avec Ruby sur Rails?

Je connais bien les concepts (pris des cours d’essais au collège), mais je ne sais pas encore comment les utiliser réellement car je n’ai jamais travaillé sur un "vrai" projet TDD.

Je suis sur le point de commencer le développement d'un projet en utilisant Ruby sur Rails (utilisant probablement la version 2.3). Cette application sera utilisée pour gérer les données, les utilisateurs et les Ce ne sera pas trop compliqué au début, mais cela risque d’être beaucoup plus lourd au cours des 6 prochains mois, alors j’estime que le moment est venu de se lancer davantage dans le TDD.

J'ai une idée de base sur la façon de le faire, mais j'ai encore besoin de quelques conseils et astuces:

  • Quel article Ruby on Rails TDD 101 devrais-je lire?)?

  • Que dois-je tester?

  • Quelle gem/plugin devrais-je utiliser?

  • Devrais-je utiliser rspec ? Autre chose?

  • Une fois tous mes cours de test terminés, comment puis-je les déployer? (par exemple: intégration continue)

  • Combien de temps prend vraiment TDD?

  • Dois-je lire un livre à ce sujet ou puis-je tout obtenir en jouant avec celui-ci et en lisant des tutoriels en ligne? Si j'ai besoin de lire un livre, quel livre?

J'aime apprendre avec des exemples pour que quelqu'un me dise comment j'adopterais une approche TDD pour résoudre ce problème:

J'ai des entreprises. J'ai des contacts. Un contact peut être lié à 1 entreprise. Une entreprise peut avoir plusieurs contacts. Je souhaite créer des moyens de créer des contacts, des entreprises et d’établir des liens avec des entreprises.

Vous n'êtes pas obligé d'utiliser cet exemple dans votre réponse, mais cela aiderait:)

ruby-on-railstestingtdd
167
marcgg

Quel article Ruby on Rails TDD 101 devrais-je lire?)?

Je vais commencer par n guide pour tester Rails applications) .

De plus, Railscast propose d’excellents screencasts sur l’utilisation de différents outils de test.

Que dois-je tester?

Je vais commencer par les modèles, car ils sont faciles à tester. La règle simple est que vous devez couvrir chaque déclaration if dans votre test.

Vous devez tester le but de la méthode (pour vous assurer qu'elle fonctionne comme prévu), ainsi que tous les cas Edge.

Assurez-vous également que vous ne finissez pas vos tests.

Quelle gem/plugin devrais-je utiliser? Devrais-je utiliser rspec? Autre chose?

Quand vous commencez, utilisez simplement Test Unit . Vous pouvez utiliser rspec ou cucumber après vous être familiarisé avec les bases.

Autotest est un outil pratique à utiliser si vous voulez être vraiment motivé par les tests. Mais c'est un 'Nice as' pas nécessaire.

Une fois que j'ai tous mes cours de test, comment puis-je les déployer?

Pas sûr de la question. Vous ne déployez généralement pas les tests. Une fois que vous avez toutes vos classes de tests, tapez simplement 'rake test' pour exécuter tous vos tests.

Combien de temps prend vraiment TDD?

Cela fait gagner vraiment du temps. Si vous aimez le casse-tête labyrinthe, vous savez qu'il est presque toujours plus facile de le résoudre si vous allez de bout en bout. Même avec TDD. Sans Test Driven, vous pensez constamment "que dois-je faire ensuite". Avec Test Driven, le test vous dira quoi faire ensuite (il se brise si la logique n’est pas présente, il vous suffit donc de réparer la pièce cassée). De plus, vous avez moins de bogues, ce qui vous fera gagner beaucoup de temps à long terme.

Dois-je lire un livre à ce sujet ou puis-je tout obtenir en jouant avec celui-ci et en lisant des tutoriels en ligne? Si j'ai besoin de lire un livre, quel livre?

Vous n'avez pas besoin d'un livre. Le moyen le plus efficace d’apprendre quoi que ce soit est: faites-le. Retournez au livre ou aux ressources en ligne lorsque vous rencontrez une question ou un problème. C'est agile aussi.

Dans votre exemple, les éléments à tester sont les suivants: un contact peut être lié à une entreprise, une entreprise peut avoir plusieurs contacts, créer des moyens de créer des contacts et lier des contacts à des entreprises.

class CompanyTest <Test::Unit
    def test_relationship # test associations/relationships
        c = companies(:some_company)
        assert_equal [a list of contacts], c.contacts # make sure a company can have multiple contacts
    end
end

class ContactTest<Test::Unit
   def  test_relationships
        c = contact(:some_contact)
        assert_equal some_company, c.company # make sure the contact link to 1 company
   end

   def  test_create/add
        # test create contacts, here you need to make sure the contact is created correctly, and linked to company correctly
   end
end
202
ez.

J'ai produit une série de 6 épisodes vidéo qui a été enseignée comme classe publique à San Francisco à l'été 2010. Le matériel couvre les tests et l'efficacité du développeur dans Rails 2.3 avec RSpec 1.3. Légèrement daté, mais les principaux concepts s’appliquent à Rails 3 avec Rspec 2.x

http://www.rubyfocus.biz/class_video/2010/07/19/Rails_tdd_class_1.html

13
Wolfram Arnold

Je recommande ce livre: Ruby on Rails Tutorial . J'ai presque terminé. Le livre utilise TDD le entier livre. Essayez!

9
sivabudh

Je recommande ce livre: Développement Web Agile avec Rails

8
JRL

J'utilise :

  1. Shoulda et rspec pour les tests
  2. Moka pour se moquer
  3. Factory_girl pour les usines
  4. parallel_specs pour des tests plus rapides
  5. metric_f pour l'analyse de code
5
Mike

TDD consiste avant tout à écrire des tests. Cela vous oblige essentiellement à écrire votre propre client avant d'écrire votre code d'application. Le cycle consiste généralement à écrire un test pour une API qui n'existe pas, exécutez le test en espérant qu'il échouera, écrivez votre code d'API, relancez le test et assurez-vous qu'il est réussi. Ensuite, écrivez votre prochain test ... et ainsi de suite.

Vous pourriez aussi être intéressé par ceci Guide Rails .

5
Andy Gaskell

Quelle gem/plugin devrais-je utiliser?

J'ai toujours apprécié shoulda .

Combien de temps prend vraiment TDD?

La raison pour laquelle j'ai toujours été favorable au développement de TDD est qu'il se concentre sur la manière dont je vais implémenter un code spécifique. J'ai le sentiment anecdotique que chaque fois que j'adhère plus fortement aux principes de TDD, je passe moins de temps à retravailler plus tard. La quantité de temps passée dépend de votre capacité à bien écrire les tests unitaires. Si les tests unitaires ne capturent pas le comportement attendu, tout le temps qui leur est consacré est perdu.

3
Patrick Robertson