Il a fallut d'abord se renseigner sur le tenant et l'aboutissant de ces tests. Après quelques recherches sur le web, je tombe sur l'excellent article de Patrick Smacchia : Les tests unitaires en pratique . Si mon billet vous met l'eau à la bouche, je vous conseille d'ingurgiter cet article, il est vraiment très instructif. L'outil que j'ai utilisé c'est NUnit (open source) vu que je programme en .Net Framework 1.1 sur mon projet actuel.

Même si le temps d'apprentissage du framework et très court on à tendance à se demander si le temps passé à écrire de tels tests est vraiment utile surtout quand la classe à développer manipule un bon nombre de données dans une base importante :bof: . C'est qu'il faut initialiser une base de données (je n'ai pas voulu utiliser d'objet Mock dans un premier temps) de tests et ça prend un bon moment surtout pour écrire les scripts de façon à ce que les tests soient dispo pour tous les membres du projet. C'est après avoir terminé tout ça que l'on voit l'intérêt de tels tests.

En effet, vu que tous les tests sont effectués en même temps, on découvre les bugs que j'appelle de "cause à effet". Vous savez la petite fonctionnalité sympa que l'on rajoute ou le bug bien connu que l'on corrige et qui vous produit tout un tas de problèmes inattendus sur d'autres propriétés ou méthodes de votre objet. Et oui traditionnellement, on test la fonctionnalité que l'on est en train d'implémenter sans repasser toutes les méthodes et fonctions de votre classe. Avec un projet de test unitaire on contrôle ainsi la non régression de votre classe et ça c'est top :rigole: Une chose que je n'ai pas aimé avec NUnit, c'est le GUI qui aurrait du nécessiter plus de tests car il plante très souvent :evil: . C'est pourquoi j'ai utilisé un plugin pour Visual Studio : TestDriven.NET mais il y en a plein d'autres. Pour ceux qui utilise SharpDevelop ou l'IDE pour Mono, NUnit est directement intégré alors pas de problèmes ;-)

La grosse erreur que j'ai faite par contre est d'avoir commencé à écrire mes tests à la fin de la période de développement. En effet, je pense qu'il est bien plus simple de faire évoluer les tests en parallèle de votre projet. La mise en place des tests sur la fin du projet prend beaucoup trop de temps à mon goût alors que le faire évoluer en même temps permet de d'entrecouper les phases de tests et de développement rendant le tout plus digeste. Pour finir je pense que de tels tests sont valables pour des projets de toutes ampleurs que se soit pour la création de programmes perso ou pro. Les deux nécessitant de la maintenance alors à vos tests ! ;-) .

Voilà c'était mon avis sur les tests unitaires.

Xavier