Lumière sur JTestR

Parmi les tâches incontournables de la vie d’un développeur, il y a l’écriture des tests unitaires. De nombreux outils tentent de nous faciliter la vie sur ce point. Aujourd’hui, je vais vous parler de JTestR, un framework de tests unitaires qui apporte la puissance et la rapidité d’écriture du scripting Ruby pour tester des applications Java. Lancé par Ola Bini, un contributeur incontournable du projet JRuby, JTestR est directement intégrable avec Ant, Buildr et Maven 2. Ce projet n’est pas encore très répandu, mais il apporte des avantages qui méritent d’être étudiés.

Tour d’horizon

JTestR est un ensemble de librairies Ruby dédiées aux tests, alliées à JRuby pour permettre un démarrage rapide et sans douleur de l’écriture des tests. L’un des atouts principaux du scripting est la rapidité d’écriture, et Ruby est un langage de scripting devenu très populaire ces dernières années, notamment grâce à Ruby on Rails. Les tests unitaires et d’intégration font partie intégrante du monde Ruby et plusieurs outils ont vu le jour pour les faciliter. JTestR embarque les librairies de test Ruby suivantes :

• Test/Unit
• RSpec
• Expectations
• Dust
• Mocha

En tant qu’outil Java, il permet également des interactions avec les frameworks :

• JUnit
• TestNG

Dans sa dernière version, JTestR nécessite l’utilisation de Java 1.6.

Intégration

Livré sous la forme d’un jar avec une tâche Ant, il est facilement intégrable dans un projet existant. Une fois le jar disponible dans votre classpath, il suffit d’ajouter une balise taskdef à votre build.xml pour plus de confort et le tour est joué:

Pour les projets Maven, une modification mineure du pom.xml fera l’affaire :

  
    org.jtestr
    jtestr
    0.4.0
    
      src/test/ruby
    
    
      
        
          test
        
      
    
  

La directive de configuration tests permet de spécifier le répertoire dans lequel chercher les scripts de tests. Pour conserver l’esprit Maven, je vous conseille de créer un répertoire src/test/ruby et d’y placer tous les tests. La hiérarchie en sous répertoires pour représenter les packages des classes à tester ne pose pas de soucis.

Rédaction des tests

JTestR offre plusieurs possibilités pour la rédaction des tests. Tout d’abord, l’utilisation du framework de tests académiques de Ruby :Test::Unit. Cela n’apporte pas de grande nouveauté par rapport aux classiques tests JUnit. Le couteau suisse de méthode assert est disponible de la même façon.

Exemple de Test::Unit

class HashMapTests < Test::Unit::TestCase
  def setup
    @map = java.util.HashMap.new
  end

  def test_that_map_is_empty
    assert @map.isEmpty
  end

  def test_that_it_returns_a_keyset_that_returns_an_iterator_that_throws_exception
    assert_raises(java.util.NoSuchElementException) do
      @map.key_set.iterator.next
    end
  end
end

Mais il est également possible d'utiliser RSpec. Ce framework de tests est orienté "spécification" et propose une notation originale qui tend à rapprocher la rédaction des tests de la spécification du comportement attendu. La notation comparée :

# avec Test::Unit
assert_equals(result, 42)

# avec RSpec
result.should == 42

On se rapproche ainsi du langage naturel. En anglais dans le texte, certes, mais on se rapproche. La structure d'un fichier RSpec complet donne par exemple :

import java.util.HashMap

describe "An empty", HashMap do
  before :each do
    @hash_map = HashMap.new
  end

  it "should not be empty after an entry has been added to it" do
    @hash_map.put "foo", "bar"
    @hash_map.should_not be_empty
  end

  it "should be empty" do
    @hash_map.should be_empty
    @hash_map.size.should == 0
  end

  it "should return a keyset iterator that throws an exception on next" do
    proc do
      @hash_map.key_set.iterator.next
    end.should raise_error(java.util.NoSuchElementException)
  end
end

Il est possible de mixer dans le même projet des tests Test::Unit et des tests RSpec. Le respect d'une norme de nommage des fichiers suffit à JTestR pour déterminer le framework ciblé.

Une précision importante sur un point obscur dans la documentation : la commande import cherche dans les packages commençant par java, javax, org et com. Pour tous les autres il faut écrire :

import Java::fr.votre.package.VotreClasse

Limitations

Un problème qui peut être pointé du doigt est le temps de chargement de l'environnement JRuby. L'interpréteur prend en effet parfois plus de 10 secondes à se lancer. Pour pallier ce problème, JTestR possède un mode serveur qui permet de conserver en tâche de fond un serveur avec l'environnement JRuby en attente des tests à lancer. On supprime ainsi facilement le temps de chargement.

L'apprentissage des bases du langage Ruby peut également rebuter, mais c'est un obstacle faible dans la mesure où c'est un langage entièrement objet et où l'on manipule majoritairement les classes Java du projet à tester. Le pas est généralement franchi assez facilement.

Conclusions

L'offre de frameworks de tests est déjà conséquente dans le monde Java. JTestR n'est pas très répandu à l'heure actuelle. Malgré cela, l'utilisation de RSpec pour la rédaction des tests permet de rester proche d'une formulation verbale des comportements attendus. Dans une démarche TDD, cela peut être avantageux. On aura ainsi tendance à éviter de se perdre dans des formulations techniques dès les premières phases du projet.

De plus, je prendrai sérieusement en considération JTestR si j'avais des développeurs Ruby dans mon équipe. Le framework vous offre une chance de casser la frontière entre vos équipes Ruby et Java. L'aspect très concis des tests les rend lisibles autant par les développeurs Java que Ruby et renforce l'entraide entre équipes. Cela facilite la distribution des compétences et des connaissances entre développeurs, ce qui n'est jamais une mauvaise chose.

Ressources :

• Le site officiel JTestR
• La documentation
• RSpec
• Test::Unit