tyPouypOblOg

Ruby bénéficie comme beaucoup d’autres langages modernes de son framework de test. Voici donc une petite documentation sur comment écrire un test unitaire pour Ruby.

Pour ceux qui ne savent pas ce qu’est un test unitaire, je vous renvoie sur l’article Test Unitaire [wikipedia]

Pour commencer il nous faut importer la librairie “Test::Unit”

require "test/unit" 

Rien que cela nous permet déjà de faire un premier test en executant notre script.

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started

Finished in 0.000607 seconds.

0 test, 0 assertions, 0 failures, 0 errors

Le fait d’inclure la librairie de test unitaire permet d’avoir un comportement par défaut qui va:

• Charger la suite de test à executer
• lancer les tests
• faire l’affichage des resultats de test
• faire un compte rendu de cette execution

Ajoutons un test maintenant

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
end

Nous avons défini une classe, celle-ci doit étendre TestCase. Cela permet au framework de test de s’y retrouver. Chaque méthode de test définie ensuite doit contenir test en début de nom (le caractère _ n’est placé que pour une meilleur lisibilité et selon les conventions couramment appliquées en Ruby)

Les méthodes assert (ici assert_equal, mais il en existe beaucoup d’autres) permettent d’effectuer un test. Ici un test d’égalité, mais nous pourrions également vérifié une différence, un bouléen répondant vrai ou faux et d’autres encore (voir la documentation sur le module Test::Unit::Assertions).

Après execution, voici le résultat:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
.
Finished in 0.000802 seconds.

1 test, 1 assertions, 0 failures, 0 errors

Un test a été executé avec succès.

Ajoutons encore un test pour avancer:

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
  def test_expression_substitution
    assert_equal("", "#{'ah! ' * 3}")
  end
end

Après exécution nous obtenons:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
F.
Finished in 0.000827 seconds.

  1) Failure:
test_expression_substitution(StringTest) [testUnit.rb:12]:
<""> expectedbut was
<"ah! ah! ah! ">.
2 test, 2 assertions, 1 failures, 0 errors

Et voilà, comme vous l’aviez deviné, nous avons une erreur. Dans notre cas, l’erreur viens de notre test.

On vois ici l’interêt de mettre chaque test sur un domaine différent dans une méthode différente: on vois facilement quel type de test nous voulions effectuer. Dans le développement d’une application complète, avec plusieurs dizaines d’objets à tester, et plusieurs dizaines de méthodes sur chacun d’eux, les erreurs d’exécution de test peuvent devenir un vrai casse-tête.

Effectuons la correction:

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
  def test_expression_substitution
    assert_equal("ah! ah! ah! ", "#{'ah! ' * 3}")
  end
end

exécution du test:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
..
Finished in 0.001273 seconds.

2 test, 2 assertions, 0 failures, 0 errors

Et voilà. Vous devriez être capables de commencer à écrire quelques tests, mais ce n’est qu’un début !.

Cet article a été écrit pour le site de l’association RubyFrance, vous pourrez le retrouver dans les documentations proposées par l’association: RubyFrance: TestUnitaire

Lundi soir, comme apparemment presque tout les lundi soir, c’est rendez-vous au dojo. Non pas celui des arts martiaux, mais celui du développement. Pour rester agiles, l’association XP-France organise des rencontres au dojo.

Dans une salle gentillement fourni par EpiConcept, des praticiens agiles se retrouvent pour un Kata voir un Randori.

J’ai passé une super soirée. J’ai découvert Haskell un langage fonctionnel pur (c’est a préciser apparemment ;-)). J’ai vu des tests, et encore des tests et c’est beau. Vivement le prochain !

Si vous voulez en savoir plus: Voir le projet Dojo sur le wiki de l’asso.

Moi je vais tenter d’y aller tout les lundi :-D

une semaine plus tard

Cet session fût très bonne. Pas loin de 30 personnes ont fait le déplacement pour cette “apéro” qui en fait ressemblait plus à une bonne présentation.

Le thème principal de ce lundi était l’agilité, l’extreme programming, les tests. En effet, des membres de l’association XP-France sont venus nous présenter l’agilité, le développement piloté par les tests le tout dans sous la forme d’un kata, une des pratiques de dojo.

Ensuite, Jean-François nous a présenter une toute nouvelle librairie ruby qui gagne à être connu: Arel également appelé ActiveRessource. Un librairie visant à permettre la création d’ORM. Disont pour résumé que cela enlèverais la couche “concaténation de chaine de caractères” dans ActiveRecord par exemple, et du coup nous aurions le moyen de construire plus joliement des requête SQL. A suivre donc.

Depuis quelque temps déjà je m’interesse aux méthodes agiles, à l’extreme programming, cette présentation à fini de me convaincre qu’il faut absoluement que j’aille en Dojo pour pratiquer le code, échanger avec d’autres personnes aguéri à ces techniques de tests et de façon de voir le code.

On en reparle plus tard ;-)