Lancer les tests unitaires fournis avec Ruby on Rails

Marche à suivre en français expliquant la manière de le faire.

On pense souvent à tort qu’il ne sert à rien de les exécuter, car le code de Rails est de manière générale stable. Les tests deviennent toutefois utiles lors de l’écriture de nouveaux plugins. En effet, les méthodes utilisées pour créer un plugin sont souvent intrusives. Que cela soit pour ajouter un nouveau DSL ou une simple méthode de classe à ActiveRecord::Base, il est nécessaire de rouvrir la classe. Le bon point, c’est que Ruby rend cette action possible et facile. La contrepartie qu’il faut être prêt à payer, c’est que rien ne prouve que la classe ainsi rouverte fonctionne toujours selon son comportement par défaut.

La procédure est très simple :

Cette approche part du principe que vous utilisez une base de données MySQL, et les configurations par défaut.

1. Créer les bases de données de test
   
   
   
   1. créer deux bases de données nommées respectivement activerecord_unittest et active_record_unittest_2.
   
   
   2. créer un utilisateur root avec le mot de passe rails
   
   
   
   


2. Exécuter les tests pour activerecord
   
   
   
   1. Aller dans le répertoire ~/rails/activerecord
   
   
   2. Exécuter rake test_mysql
   
   
   
   


3. Exécuter les tests pour actioncontroller
   
   
   
   1. Aller dans le répertoire ~/rails/activerecord
   
   
   2. Exécuter rake test
   
   

Limitation de cette approche pour tester un plugin

Gloabalize Rails utilise extensivement les propriétés de Ruby qui permettent de rouvrir les classes. Ainsi il est possible de redéfinir des méthodes incluses dans les classes de Ruby On Rails. Les tests unitaires de Rails devraient nous permettre de nous assurer que rien n’est cassé dans le comportement par défaut du framework.

Théoriquement, les tests unitaires servent à tester la plus petite unité possible, généralement une fonction. Il ne sont pas conçu avec l’idée de réutilisation. Toutefois Ruby permettant de rouvrir des classes existantes, il faudrait pouvoir relancer ses mêmes tests dans un autre contexte, dans le but de prouver que le comportement par défaut n’a pas changé.

Malheureusement, il est très difficile d’exécuter ses tests en chargeant tout d’abord le plugin. Le principal obstacle réside dans le fait que chaque fichier de test unitaire définit ses propres classes et modèles. Il faudrait donc les modifier à la volée. Yann m’a proposé hier de faire de l’injection de code pour y parvenir. Cela me parait fastidieux comme approche mais je n’ai rien trouvé de mieux pour l’instant. Une idée ?

Les sources exclusives utilisées pour ce billet sont les différents fichiers RUNNING_UNIT_TESTS des librairies rails. N’hésitez pas à vous y référer pour de plus amples informations.