Tout le monde s’accorde sur l’utilité des tests de non régression automatisés, d’ailleurs les outils disponibles dans la sphère Java sont légion : jUnit, dbunit, jmock …
Mais de là à les voir mis en oeuvre systématiquement sur les projets il y a un pas ; l’un des reproches revenant le plus est : « les tests sont trop coûteux à écrire ».
Unitils est une bonne réponse à ce problème.
Il s’agit d’un framework « de glue » permettant d’intégrer des frameworks comme jUnit, dbUnit, Spring, EasyMock… afin de simplifier le développement de tests de non régression en tous genres.
Ci-dessous un exemple illustre la concision avec laquelle on est désormais capable de tester un accès à la base de données.
La classe de test …
@SpringApplicationContext("com/octo/javacoc/applicationContext.xml")
public class BookDaoTest extends UnitilsJUnit4 {
@SpringBean("bookDao")
private IBookDao bookDao;
@DataSet
@Test
public void testFindAllBooks()
{
Listbooks = this.bookDao.findAllBooks();
ReflectionAssert.assertPropertyLenEquals(
"author",
Arrays.asList("Jules Vernes", "JRR Tolkien", "Isaac Asimov"), books);
}
}…. avec le jeu de données correspondant :
<dataset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="dataset.xsd">
<book id="1" title="20000 lieues sous les mers" author="Jules Vernes"/>
<book id="2" title="Le Seigneur des anneaux" author="JRR Tolkien"/>
<book id="3" title="Fondation" author="Isaac Asimov"/>
</dataset>En usant habilement des annotations et du paradigme « convention over configuration » [1], Unitils permet de considérablement réduire le volume de code des tests fixtures [2] afin de se concentrer sur la logique de test.
Un autre exemple de code illustre la déclaration simplifiée de mocks dynamiques [3] .
@Mock
@InjectInto(property="bookDao")
private IBookDao mockBookDao;
@TestedObject
private BookService bookService;2008 : l’année du Java light?
Cet outil s’inscrit dans la mouvance actuelle de simplification des développements Java : nous somme tous rassasiés par 4 ans de boulimie XML (Spring inside) et bientôt gavés par des kilotonnes d’annotations. Face au poid-plume Grails, Java parait bien pénible pour réaliser nos plus petites applications de gestion. Ainsi je prédis que 2008 sera l’année de la cure pour enfin obtenir un Java allégé aux saveurs de CoC [1] et de DRY [4] !
Pour en revenir à Unitils, il vient de sortir en version 1.0, est disponible dans vos repos maven préférés et pour ne rien gâcher est particulièrement bien documenté et supporté. Bref du tout bon, et on attend la suite ! (tests de webservices ? support des tests contexts de Spring 2.5 ? …)
[1] Convention over Configuration
[2] Test fixture
[3] Mock dynamique
[4] Don’t Repeat Yourself
5 commentaires sur “Simplifier le développement des tests avec Unitils”
Puisse ta prédiction se réaliser!
En fait, je pense que nous n'avons pas besoin de nouveaux frameworks pour faire du java-light. Tout est déjà disponible et marche très bien. La question n'est pas tant pour moi 'quel framework de glue ajouter' mais plutôt 'quels frameworks supprimer'.
Par exemple, tu cite les frameworks de test jUnit, dbunit, jmock. Je pense que dbunit et jmock sont tous les deux inutiles dans 99% des cas. Un Junit pourra les remplacer dans la très vaste majorité des cas IMHO.
Du coup, il devient intéressant de se demander à quoi ressemblerai ces applis. Quels patterns? Quels savoir-faire développer pour les maitriser sans (re)tomber dans les travers du passé?
Je ne pense pas que l'on ait des masses de frameworks à supprimer (pour jMock on peut souvent s'en passer, mais pour dbunit c'est peut etre le framework de test le plus utilisé dans certaines applis de gestion).
Ensuite sur les core-frameworks existant, je pense que l'on a déjà effectivement pas mal de choses bien disponibles : Hibernate, Spring 2.5, reste à s'accorder sur la GUI. Et tous les framework tendent aujourd'hui à la simplification (moins de code, moins de conf)
Mais tu parles de patterns et je pense que c'est surtout là qu'il faut agir : aujourd'hui on les subit beaucoup plus qu'on les choisit. DAO, DTO, VO, multiproject ... Et au final ca plombe la productivité.
Christian,
J'aime beaucoup la notion que tu propose 'choisir plutôt que subir'. Une voie possible serait peut être de lister/cataloguer ces patterns et les proposer aux équipes plutot que les imposer comme des 'reco'.
Par exemple, l'équipe a le choix d'utiliser ou pas une base de données relationnelle pour ces tests unitaires. Si elle fait ce choix, dbunit prend tout son sens, sinon, elle n'en a pas besoin. Idem pour DTO, multiproject etc...
L'idéal serait aussi d'éviter les analyses du type 'avantage/inconvénient'. Ces informations sont pour moi le reflet des gouts de celui qui a cataloguer les patterns, qui peuvent être différent de celui de l'équipe. Par exemple, utiliser une base relationnelle pour les tests est un inconvénient pour moi, et probablement un avantage pour d'autres personnes. J'aurai du mal à dire qui a raison ou tord dans l'absolu. Il serait peut être plus pertinent de lister les conséquences de ces choix et chacun considera ces conséquences selon son contexte/expérience comme un avantage ou un inconvénient.
Completement d'accord. Je trouve les comparaisons intéressantes cependant il manque trop souvent les informations sur le contexte qui fait qu'il s'agit d'un + ou d'un -. Un même argument pour un produit/framework peut se transformer en l'un ou l'autre en fonction du contexte.
Dans la même lignée 'compléter la fiche des core patterns JEE' je pense qu'un laïus sur ce qui a motivé la création du pattern peut être intéressant pour se reposer des questions sur le bien-fondé de son utilisation aujourd'hui.
J'ai l'impression que l'on perd l'essence du pattern qui est 'problème -> solution' en appliquant la solution avant même d'avoir mal.
L'exemple le plus marquant de pattern qui a la peau dure est le DTO qui était motivé à l'origine par l'impossibilité de faire transiter sur le réseau les premières générations d'EJB entity (qui sont non sérialisables)