|
|
 |
Outil par défaut des tests unitaires, JUnit s'est imposé comme la solution la mieux conçue pour vérifier les bonnes réactions du code à certaines données - automatiquement.
Propulsé sur le devant de la scène par le succès de l'Extreme Programming (XP), le développement piloté par les tests (Test-Driven Developpement ou TDD) est devenu une évidence implacable : on ne peut être certain du bon fonctionnement d'un morceau de code, qu'à partir de moment où l'on en a testé toutes les possibilités d'erreur.
Le principe du TDD est donc, avant même d'écrire le code d'une fonctionnalité, d'écrire le test pour ce futur code. Une fois le test écrit, le code de la fonctionnalité devra toujours passer correctement le test avant de pouvoir valider celle-ci.
Chaque fonctionnalité peut donc se retrouver avec plusieurs tests sur le dos, chacun vérifiant d'une manière différente le bon fonctionnement d'une petite partie de l'application. Parce qu'une application complète peut disposer de plusieurs milliers de tests, l'automatisation devient nécessaire.
C'est ici qu'entre en jeu l'architecture de test JUnit, destinée à tester le code Java. Plus largement, tous les langages activement utilisés disposent de leur équivalent xUnit : PHPUnit pour PHP, nUnit pour les langages .Net, ou AS2Unit pour ActionScript 2.0. Tous dérivent de SUnit pour Smalltalk, conçu par Kent Beck, par ailleurs l'un des instigateurs du mouvement Extreme Programming. Beck a ensuite porté SUnit vers Java avec l'aide d'Erich Gamma, l'un des auteurs du livre fondateur sur les design patterns, et l'un des meneurs du projet Eclipse.
Tutoriel réalisé par Xavier Borderie, JDN Développeurs
|
En savoir plus
