Discussion :

[Julien Bodin]

Bonjour à tous !

Ca va faire une bonne année que je développe et conçoit des applications en Java.
Je remarque qu'un des plus gros problèmes actuellement ce sont les régressions au niveau des fonctionnalités. Certaines fois quand je vais modifier une classe ça va empêcher un autre bout de code de fonctionner.

A priori la mise en place de tests unitaires serait une bonne pratique permettant d'éviter ces régressions.
Connaissez-vous de bonnes ressources (web, livres...) concernant les tests unitaires et le TDD (Test Driven Developpment) ?

Merci d'avance pour vos conseils

[super_toinou]

Hello,

pour ma part je suis assez fan de l'intégration des test unitaires dans maven.

Les rapports générés sont très corrects et le nombre de plugin ajoutables pour effectuer les tests est impressionnant (ex : DBUnit).

Si en plus de ça tu rajouter du contrôle continue avec Hudson ou Continum t'es au top

+++

[Jimmy_]

Certaines fois quand je vais modifier une classe ça va empêcher un autre bout de code de fonctionner.

Si ton objet est mal programmé, ce n'est pas des tests unitaires qui vont t'enlever un couplage fort. Ca doit venir en plus et pas pour palier des erreurs de code.

[super_toinou]

Effectivement,

de l'intégration continue te permettra de détecter ces types de problèmes facilement.

[Julien Bodin]

Si ton objet est mal programmé, ce n'est pas des tests unitaires qui vont t'enlever un couplage fort. Ca doit venir en plus et pas pour palier des erreurs de code.

Et s'il était bien programmé à quoi me serviraient les tests unitaires ?

[Jimmy_]

Et s'il était bien programmé à quoi me serviraient les tests unitaires ?

Un outil quel qu'il soit ne corrigera jamais une erreur de code.
Jusqu'à preuve du contraire, maven ou junit, n'ont jamais factorisé du code ou découpler des classes.

[Julien Bodin]

D'accord. Tu pars donc du postulat que je code mal.
Donc je n'ai pas besoin de m'intéresser aux tests unitaires.

Je ne vois pas l'intérêt d'utiliser des tests unitaires si on code sans erreurs.

Pour moi justement ça permet de pouvoir faire des grosses refactorisation sans casser le code, entre autres.

[tchize_]

Personellement, j'ai appris sur le tas, ce n'est pas ce que je recommanderais, trop de temps perdu. Je peux te proposer deux voies, celle payante et celle a pas cher.

Coté payant, pour y avoir envoyé récement deux de mes collaborateurs, une formation de 2 à 3 jour par un boite pro de formation, c'est en général 2000€bien investis Depuis deux ans j'essaie de les convaincre d'écrire leur test avant les code. En 2 jours de formations, ils ont complètement changé de méthodes de travail.

Coté gratuit, pour te mettre dans le moule, il y a l'agile tour, ou régulièrement sont organisés de dojo Test driven development ou autres.

Et même quand on code bien, n'en déplaise à certains, un changement d'un coté, peu avoir beaucoup d'influence de l'autre. Si demain j'ajoute un champ obligatoire dans bean d'un coté, c'est peut etre un composant à l'autre bout de la chaine qui déconnera. Avec des test unitaires et des test d'intégration, on peu faire d'énormes refactoring sans avoir peur de passer des semaines à corriger. Au pire, si on casse trop, on vois tout suite où il faut faire le rollback

Et comme on a plus peur de faire du refactoring, comme du jour au lendemain on peut changer en 2h de boulot les 2/3 du shéma de classe en étant sur que tout marche encore après, ben on peu se permettre de construire l'architecture au fur et à mesure qu'on développe, plutot que de mettre en place un phase d'analyse couteuse. Et là on tombe en plein dans le développement agile

Et Hudson + maven avec ça, t'es sur un nuage. Tu fait ton bout de code et tu t'emmerde meme plus de savoir si il marche bien avec tout ni à lancer tous les tests, tu laisse hudson faire :p

[Drawingrom]

Un lien et des bouquin :
http://www.katacasts.com/ <- katas en vidéo, même pas besoin de bouger

Un livre en général : Coder Proprement de Robert C. Martin

Les bouquins de Kent Beck sont forcément intéressants (mais je n'en ai pas lu...)

Un dernier sur lequel je suis en ce moment "Working Effectively With Legacy Code" de Michael Feathers. Tout est dans le titre... même s'il aurait pu s'appeler "Comment écrire des tests unitaires pour du code dégueulasse". Très très bon.

Pour trancher ce qui s'est dit dans le thread, ce qu'on peut lire dans ce genre de bouquin est que du code qui n'est pas couvert de tests unitaires est du mauvais code . Comme le dit tchize_, faire évoluer du code couvert par des TU, c'est vraiment un plaisir (mais c'est tellement rare !).

[Julien Bodin]

Merci pour vos réponses.

J'ai également acheté le livre "Coder proprement" de Robert C. Martin, c'est un des meilleurs investissement que j'ai pu faire jusqu'à présent.

Je vais chercher des infos à propos de "Working Effectively With Legacy Code" qui peut m'intéresser étant donné que le "legacy code", c'est le mien

Dans le cadre d'un stage longue durée (au cumul ça va faire plus de 8 mois) j'ai commencé la programmation véritablement (=> ailleurs qu'en cours) sur une application que je continue de développer actuellement.
Je reviens régulièrement sur les anciennes parties de code que j'ai pu faire quand j'ai débuté pour les mettre à mon niveau actuel. Le problème étant que ces morceaux de code sont fortement couplés et que certaines fois en cas de modifications mes utilisateurs se "plaignent" de régressions. J'aimerais consolider tout ça tant que l'application n'est pas critique (=> application en cours de dev et donc de test).