Discussion :

[Elendhil]

Voilà je voudrais pour mes futures projets me mettre à écrire systématiquement des tests unitaires.

On parle souvent de "test-driven" c'est à dire écrire d'abord les tests puis le code fonctionnel. Cela me semble pas mal comme méthode à première vue , mais je me dis que ça doit vraiment pas être simple de coder comme ça ?

Combien de temps avez-vous mis pour commencez à appréhender cette méthode de développement ?

Es que cela vous a permis réellement de réduire le temps de développement sur vos projets ? Es que c'est valable même sur des projets de "taille réduite" quelques milliers de lignes de codes ?

Y-a t'il une démarche à avoir pour écrire les tests ? comment fait vous pour savoir si tout est bien testé ? Quand le projet dépend de nombreux frameworks ou s’exécute sur un serveur d'application cela pose pas de problème ?

Enfin voilà j'aimerais bien un retour d'expérience sur le test-driven et même sur l'écriture de test en général.

Merci.

[kolodz]

On parle souvent de "test-driven" c'est à dire écrire d'abord les tests puis le code fonctionnel. Cela me semble pas mal comme méthode à première vue , mais je me dis que ça doit vraiment pas être simple de coder comme ça ?

En réalité, c'est assez simple. Avant d'écrire une méthode tu va faire un test qui vérifie son comportement.
L'avantage de cette méthode, c'est de bien spécifié le comportement attendu. Cela permet de réduire le temps de débogage et améliore la conception. Parfois l'écriture du test suffit à comprendre que l'architecture n'est pas correct pour ce que l'on veux faire.

Es que c'est valable même sur des projets de "taille réduite" quelques milliers de lignes de codes ?

Cela dépend des personnes... Certains sont capable de voir la globalité de leur code avant de commencer et prévoir les effets de bord. Mais si le projet peut être réutiliser par une autre personne (ou soit même mais plus tard) cela permet d'éviter beaucoup d'erreur dans les modifications.
L'investissement n'est pas énorme et c'est une bonne habitude à prendre.

Y-a t'il une démarche à avoir pour écrire les tests ?

1. Fonctionnement normale
4/2=2
2. Fonctionnement aux limites
4/0=>Erreur ou Infini selon la spécification voulu.

comment fait vous pour savoir si tout est bien testé ?

C'est une grande question qui n'a pas de réponse toute faite.
Il existe des outils de couverture de code. (si tu passe bien dans toutes les lignes)
D'autres outils existent, mais ils sont encore dans le domaine du PoC.

Quand le projet dépend de nombreux frameworks ou s’exécute sur un serveur d'application cela pose pas de problème ?

Les frameworks ne posent pas de problème. Mais il faut savoir qu'ils ont aussi des erreurs. (Certains l'oublie)

Les serveurs d'application ne pose pas de problème. C'est les rendu graphique et les interfaces utilisateurs qui sont plus compliquer à tester de cette manière.

Enfin voilà j'aimerais bien un retour d'expérience sur le test-driven et même sur l'écriture de test en général.

Un test réussi ne veux pas dire qu'il n'y a pas d'erreur, juste que le test et l'application sont compatibles (les deux peuvent être faux)
Il faut toujours savoir si c'est le test(/spécification) ou le code qui est faux.

Et pour finir les tests ne remplace pas la documentation. Mais celle-ci doit expliquer ce qui est tester.


Cordialement,
K

[tchize_]

C'est un pli a prendre mais il n'est pas bien dur a prendre. Une règle violable que j'ai apprise c'est max 5 minutes de test, max 5 minutes de code:

1) tu écrit un test, simple, qui doit foirer
2) quand il foire, tu écrit le code simple qui corrige l'erreur
3) quand il réussi, tu écrit du code supplémentaire dans le test qui le faire foirer
4) retourner au point 2


Exemple tout con: je veux une classe qui implémente un feuille de calcul excel. Je dois avoir des cellules dans lesquelles je peux stocker des valeur et des formules. Je vais avoir cette logique de développement:


TEST

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void testTableur(){
    Feuille f = new Feuille("feuille1"); // erreur feuille n'existe pas
}

Code principal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void class Feuille{
    public Feuille(String name){}
} // super maintenant ca marche

TEST

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public void testTableur(){
    Feuille f = new Feuille("feuille1"); 
    assertEquals(f.getName(),"feuille1"); // humm pas de méthode getName()
}

Code principal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public void class Feuille{
    public Feuille(String name){}
    public String getName() {return "feuille1"} // hé, quoi? ca marche!
}

TEST

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public void testTableur(){
    Feuille f = new Feuille("feuille1"); 
    assertEquals(f.getName(),"feuille1");
    Feuille f2 = new Feuille("feuille2"); 
    assertEquals(f2.getName(),"feuille2"); // on croise les tests pour éviter ce genre de blague :)
}

Code principal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public void class Feuille{
    private String name;
    public Feuille(String name){this.name=name;}
    public String getName() {return name;} //mieux
}

TEST

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public void testTableur(){
    Feuille f = new Feuille("feuille1"); 
    assertEquals(f.getName(),"feuille1");
    Feuille f2 = new Feuille("feuille2"); 
    assertEquals(f2.getName(),"feuille2"); 
    f.put("A1","Bonjour");
    assertEquals(f.get("A1"),"Bonjour");

Code principal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public void class Feuille extends HashMap<String,Object>{ // tout con :)
    private String name;
    public Feuille(String name){this.name=name;}
    public String getName() {return name;} 
}

etc, etc

[Logan Mauzaize]

On parle souvent de "test-driven" c'est à dire écrire d'abord les tests puis le code fonctionnel. Cela me semble pas mal comme méthode à première vue , mais je me dis que ça doit vraiment pas être simple de coder comme ça ?

Au contraire ! Tu commences par coder l'utilisation de la classe et non son comportement. Parfois ça change énormément la donne !

Combien de temps avez-vous mis pour commencez à appréhender cette méthode de développement ?

Si tu connais déjà JUnit ou TestNG, ca te prendra aucun temps. Puisqu'il s'agit de coder.

Es que cela vous a permis réellement de réduire le temps de développement sur vos projets ?

A long termes ca ne fait pas vraiment gagner de temps de développement mais ça améliore la traçabilité et la qualité.
Limité le nombre de retours en intégration/recette/acceptance/production et l'image de marque du MOE n'ont pas pas de prix !

Es que c'est valable même sur des projets de "taille réduite" quelques milliers de lignes de codes ?

C'est toujours valable, mais c'est surtout la complexité qui primes.

Y-a t'il une démarche à avoir pour écrire les tests ?

La démarche est d'écrire d'abord l'utilisation d'une classe (ou d'une série de) classe(s) (un genre de snippet).
Ensuite tu codes les tests unitaires à proprement parler.
Je te conseille de faire une multitude de tests avec un minimum d'assert. Ca permet de mieux localiser les erreurs.

comment fait vous pour savoir si tout est bien testé ?

Tu peux utiliser des outils de couverture de code. Je te recommende Cobertura qui fait de la couverture au niveau ligne, mais tu as des outils qui font de la couverture de branches (Clover je crois).

Quand le projet dépend de nombreux frameworks ou s’exécute sur un serveur d'application cela pose pas de problème ?

C'est très variable.
Et je dirais qu'il faut faire avec et sans.
Sans il faut bouchonner/simuler le contexte d'exécution. Soit tu le fais toi-même, soit il existe des frameworks spécialisés comme Mockito, JMockIt, etc.

Enfin voilà j'aimerais bien un retour d'expérience sur le test-driven et même sur l'écriture de test en général.

C'est une excellente démarche qui permet d'augmenter la qualité et l'utilisabilité d'un code. Et sur ce dernier point, c'est la seule méthode démarche que je connaisse qui soit assez efficace.

Ensuite ça représente un certain coût. Le temps que tu passes à faire des tests complexes c'est du temps en moins pour le reste du projet (pas uniquement le développement !!!).
D'autant plus si les spécifications bougent souvent (que ce soit au cours d'une version ou d'une version à l'autre), ça à tendance à faire péter un gros paquet de test.

Concernant la démarche en elle-même. Je suis partisan des points suivants :

1. Partitionner les tests par catégorie (groupe fonctionnelle, complexité, cohérence technique, sujet d'application, acteur concerné). Avec TestNG c'est plus simple en associant des "mots clés", avec JUnit il faut créer un TestSuite pour chaque combinaison de catégories. Un test doit pouvoir faire partie de plusieurs catégories.
2. Ecrire des tests unitaires, d'intégration, de validation, etc. Il s'agit d'enlever au fur et à mesure les systèmes "bouchonner"/"simuler". Plus il y a de test automatique, plus ça coûte mais plus tu peux les jouer souvent. Notamment dans un système d'intégration continue (CruiseControl par exemple, que je préfère à Hudson personnellement)
3. Utiliser un système d'intégration continue et planifier correctement l'exécution des tests par catégorie/type
4. J'ai tendance à créer des tests catégorisés "complexe" et "aléatoire". Ceux-ci consistent à générer des entrées aléatoires et lancer une batterie de tests. Il faut prévoir un système de sauvegarde des entrées générées en cas de problèmes et de nettoyage dans le cas où tout va bien. C'est également plus simple avec TestNG.

[professeur shadoko]

En réalité, c'est assez simple. Avant d'écrire une méthode tu va faire un test qui vérifie son comportement.
L'avantage de cette méthode, c'est de bien spécifié le comportement attendu. Cela permet de réduire le temps de débogage et améliore la conception. Parfois l'écriture du test suffit à comprendre que l'architecture n'est pas correct pour ce que l'on veux faire.

jchuis bien d'accord, mais j'ai juste du mal à comprendre quelque chose: mais vous faites ça comment avec JUnit?
j'aime écrire des tas de tests avant d'écrire le code et j'aimerai bien passer certains tests au fur et à mesure: or ces tests ne se compilent pas tant que les méthodes correspondantes ne sont pas écrites .... j'aimerai avoir un résultat de test du type "code non encore réalisé" et les autres passent ou ne passent pas. ceci est une plaidoirie pour des tests interprétés et non pas compilés : votre avis?

[-gma-]

jchuis bien d'accord, mais j'ai juste du mal à comprendre quelque chose: mais vous faites ça comment avec JUnit?
j'aime écrire des tas de tests avant d'écrire le code et j'aimerai bien passer certains tests au fur et à mesure: or ces tests ne se compilent pas tant que les méthodes correspondantes ne sont pas écrites .... j'aimerai avoir un résultat de test du type "code non encore réalisé" et les autres passent ou ne passent pas. ceci est une plaidoirie pour des tests interprétés et non pas compilés : votre avis?

Tu définis des interfaces et leurs contrats respectifs. Tu peux ensuite écrire et compiler tes tests en utilisant ces interfaces. Enfin tu peux coder tes implémentations, méthode par méthode si tu en as envie.

Ça fait peut être un peu cas d'école mais ça me parait quand même applicable.

[Logan Mauzaize]

Eclipse génère des .class pour des classes non compilées. A l'exécution ca renvoie une exception sur le chargement de la classe.
En revanche je ne sais pas si le .class contient une "description" (méthodes attributs, annotations) de la classe.

Ceci dit la compilation est une première phase d'exécution au sens TDD. Donc la première phase du test va échouer, avec plus ou moins de chance de poursuivre en seconde phase.
C'est le même principe du test unitaire qui s'arrête sur le premier assert qui échoue. D'ailleurs pour un projet on a modifier le mécanisme de JUnit pour permettre le contrôle de plusieurs assertions.
De même on devrait gérer une dépendance entre tests. De sorte que si un test bas niveau échoue, le test de plus haut niveau qui repose sur la fonctionnalité testée ne soit pas lancée.
JUnit propose un mécanisme de contrôle de la "faisabilité" d'un test. En gros ce sont des assertions mais si elles échouent, elles ne sont pas considérés comme un test KO.
Dans TestNG il y a une notion de dépendance.

[Elendhil]

Merci pour toutes ces réponses ! Cela démystifie un peu la chose, cela me semble plus si compliqué.

Tchize_ , le code que tu as écris c'étais juste pour me montrer l'utilisation/création de tests , je suppose que l'on teste pas des cas si simple quand même ? Genre getter/setter , constructeur sans arguments ect ... ? Ou faut quand même le faire ?

Sinon j'ai lu quelques articles sur le sujet , et je commence à lire un livre dont certains chapitres concernent ce thème.
Mais disons qu'à première vu cela ne me semblait pas naturel , le fait d'écrire un test sur une fonction dont tu ne sais pas toujours comment tu vas l'écrire ^^.
Vous avez surement raison c'est juste un pli à prendre.

Et l'autre problème que je voyais , on vois souvent des commentaires sur le net, disant mouais bof cela double le temps de développement et il y a jamais la garantie que le programme n'aura pas de bugs, donc sous entendu ce n'est que du temps de perdu.

D'où ma question pour savoir ce qu'en pense des professionnels tel que vous , apparemment vous êtes tous convaincu !

Autrement l'avantage qui m'importe le plus c'est toujours de pouvoir réduire le temps de développement.
Je comprend que c'est pas le but premier mais bon il n'est pas possible de lancer une application, un service, un jeu totalement bugué ce n'est pas acceptable.
Donc on perd énormément de temps quand on développe car on ajoute petit bout par petit bout , à chaque fois on relance l'application on test si ça fonctionne , merde non la j'ai écris une connerie paf tu retournes modifier tu relances ect ...

Et puis bon on est censé toujours appliquer certaines règles pour bien programmer nom de variables bien choisi, méthodes courtes, classes qui font qu'une chose, éviter au max les interdépendances ect..
Mais en pratique , j'ai du mal à m'y tenir je me retrouve pas mal de fois avec des méthodes beaucoup trop longues(genre 20 -30 lignes) , classes avec énormément de méthodes, beaucoup de classes qui dépendent les unes des autres (surtout partie graphique).
Donc quand tu veux changer quelques choses , je parle avant que l'application soit finalisé avec justes quelques bugs, he bien c'est toute suite la galère.

D'où mon intérêt pour cette méthode de programmation qui je pense va m'obliger à garder toujours une certaine "discipline" sur mon code. Par exemple coder un test unitaire sur une méthode qui fait 30 lignes doit pas être facile ^^. Donc avec tdd même si je met plus de temps à écrire une méthode, fonctionnalité+test sur l'ensemble du projet je vais réduire de beaucoup le temps pour créer l'app par rapport à coder à l'arrache ^^

En tous cas merci pour vos réponses.

[tchize_]

j'aimerai avoir un résultat de test du type "code non encore réalisé" et les autres passent ou ne passent pas. ceci est une plaidoirie pour des tests interprétés et non pas compilés : votre avis?

Eclipse (et il me semble que maven aussi) remplace les lignes non compilables par un "throw new RuntimeException(message)" avec message étant le message d'erreur du compilateur. Ainsi, presque à tous les coups, le test se lance même si les méthodes n'existent pas Pas besoin d'interprété pour ça :p

[tchize_]

Merci pour toutes ces réponses ! Cela démystifie un peu la chose, cela me semble plus si compliqué.

Tchize_ , le code que tu as écris c'étais juste pour me montrer l'utilisation/création de tests , je suppose que l'on teste pas des cas si simple quand même ? Genre getter/setter , constructeur sans arguments ect ... ? Ou faut quand même le faire ?

Ben tu notera que j'ai testé qu'il existe un classe Feuille, possédant un nom persistant et qui persiste les valeur que je passe aux cellules

C'est tout ce que fait le test pour le moment.
Le assert sur getName(), ca coute pas cher à écrire
Le assert sur le get() t'as besoin de l'écrire sinon comment savoir que la classe stocke correctement? Bien sur on ne teste pas tous dans les moindre détails, souvent les getters/setters basiques, on ne les teste pas. Mais dès qu'une logique est demandée, en général on les test (ex: tester la logique "si je fait un set avec un nombre négatif, ca stocke 0")

[Robin56]

Mais disons qu'à première vu cela ne me semblait pas naturel , le fait d'écrire un test sur une fonction dont tu ne sais pas toujours comment tu vas l'écrire ^^.
Vous avez surement raison c'est juste un pli à prendre.

Je donne juste mon avis bien que je ne fais pas assez de tests pour te donner des conseils ^^

En fait, dans ce principe là, l'encapsulation de Java est agréable. Au final, la logique derrière, tu ne sais pas comment la faire mais c'est pas le problème pour le moment. Toi ce que tu sais c'est que tu auras besoin d'une méthode qui aura besoin de tel(s) paramètre(s) et qui devra te donner tel retour. En se limitant à se raisonnement, je trouve qu'on arrive déjà mieux à mettre des tests très tôt dans les phases d'un projet.

Après, ça nécessite de bien avoir pensé ton application dès le début (spécification, conception).

[Logan Mauzaize]

Eclipse (et il me semble que maven aussi) remplace les lignes non compilables par un "throw new RuntimeException(message)" avec message étant le message d'erreur du compilateur. Ainsi, presque à tous les coups, le test se lance même si les méthodes n'existent pas Pas besoin d'interprété pour ça :p

Personne ne lit mes réponses

Tchize_ , le code que tu as écris c'étais juste pour me montrer l'utilisation/création de tests , je suppose que l'on teste pas des cas si simple quand même ? Genre getter/setter , constructeur sans arguments ect ... ? Ou faut quand même le faire ?

Comme l'ont dit Tchize_ et kolodz, tu testes surtout les conditions et les limites (gestion de la valeur null par exemple).

Sinon j'ai lu quelques articles sur le sujet , et je commence à lire un livre dont certains chapitres concernent ce thème.
Mais disons qu'à première vu cela ne me semblait pas naturel , le fait d'écrire un test sur une fonction dont tu ne sais pas toujours comment tu vas l'écrire ^^.
Vous avez surement raison c'est juste un pli à prendre.

Disons que la démarche est surtout là pour te forcer à penser à l'utilisabilité plutôt qu'au fonctionnement. Comme la plupart des applications sont conçues comme un oignon (superposition et agencement de couches de services/API), c'est une approche beaucoup plus logique.

Et l'autre problème que je voyais , on vois souvent des commentaires sur le net, disant mouais bof cela double le temps de développement et il y a jamais la garantie que le programme n'aura pas de bugs, donc sous entendu ce n'est que du temps de perdu.

Certes ça prend du temps et ça n'empêche pas les bugs mais :

1. Cela évite qu'un même bug se reproduise ou soit réintroduit ultérieurement. Car tout bug doit faire l'objet d'un (ou plusieurs) test(s) et qui doivent être gardés dans la base de tests.
2. Dans la même veine, cela permet également de corriger l'ensemble des causes d'un problème fonctionnelle (car souvent les bugs qui arrivent post-développement sont une accumulation de petits bugs techniques). J'ai trop souvent vu des bugs à moitié corriger car toutes les causes n'avaient pas été correctement identifiées.
3. Cela permet de diagnostiquer beaucoup plus rapidement l'origine d'un bug plutôt que de passer des heures dans le debugger. A condition que les tests soient bien faits.
4. Cela permet d'assurer la non-régression.

D'où ma question pour savoir ce qu'en pense des professionnels tel que vous , apparemment vous êtes tous convaincu !

Je pense que tu n'appliqueras que rarement le pur TDD. En tout cas cela ne m'est jamais arrivé. Mais j'ai ma démarche à ma sauce

Autrement l'avantage qui m'importe le plus c'est toujours de pouvoir réduire le temps de développement.
Je comprend que c'est pas le but premier mais bon il n'est pas possible de lancer une application, un service, un jeu totalement bugué ce n'est pas acceptable.Donc on perd énormément de temps quand on développe car on ajoute petit bout par petit bout , à chaque fois on relance l'application on test si ça fonctionne , merde non la j'ai écris une connerie paf tu retournes modifier tu relances ect ...

La démarche ne te fera pas gagner du temps (sauf si t'es le roi pour introduire des bugs )
En développement, en fonction de sur quoi tu travailles, tu devrais définir une catégorie de tests à repasser (d'où l'importance de "tagger"/"catégoriser" les tests).
Car le temps d'exécution des tests va rapidement grimper vers plusieurs minutes, voir plusieurs heures.

Après, ça nécessite de bien avoir pensé ton application dès le début (spécification, conception).

Justement la démarche TDD permet de faire la conception à travers les tests. Tu définis les classes et leurs propriétés, la signature des méthodes au fur et à mesure des besoins. Tu écris également les séquences d'appels, etc.
D'ailleurs dans une démarche pur TDD, un algorithme (et/ou le corps d'une méthode) est d'abord écris dans un (ou plusieurs) test(s) avant d'être intégré dans une méthode. Et c'est ensuite par refactoring que le code est intégré dans une classe et/ou méthode et les tests écrits sont mis à jour en conséquence.



Un point qui n'a pas encore été abordé c'est le fait que la démarche TDD s'inscrit normalement dans une méthode "agile", notamment l'eXtreme Programming

[tchize_]

si si on gagne du temps.

Quand t'as un application qui met 3 minutes à démarrer, que t'as 15 clic à faire pour arriver sur la partie que tu veux tester. C'est plus rapide de lancer un test qui te sort ses conclusions en 2 secondes

Bien sur ca ne te dispense pas du gros test, mais tu le fait moins souvent (1 fois par heure disons), quand la fonctionnaltié a tester est bien avancée

Bon maintenant si tu utilise des trucs comme JRebel , tu évite en général aussi le redémarrage de l'application pour tester ton code, mais c'est une autre histoire :p

[Robin56]

Bon maintenant si tu utilise des trucs comme JRebel , tu évite en général aussi le redémarrage de l'application pour tester ton code, mais c'est une autre histoire :p

Je viens de voir la vidéo de présentation, ça a l'air sympa. Je garde ça sous le coude

[ManusDei]

Je te conseille de faire une multitude de tests avec un minimum d'assert. Ca permet de mieux localiser les erreurs.

Pourquoi un minimum d'assert ?
Personnellement je m'en sers pour vérifier que j'ai le bon résultat (ou au contraire l'erreur prévue).

[Logan Mauzaize]

Il est préférable de multiplier les tests que les asserts dans un test car sinon tu perds en finesse/granularité car une seule partie du test sera exécuté.

Si t'as besoin qu'une série d'opération soit réalisée et conforme avant d'en faire une autre, il vaut mieux utiliser les assomptions (pour JUnit) ou les dépendances (pour TestNG)

Ou sinon mettre en place un système de multi-assertion.