Discussion :

[randriano]

Bonjour,

J'aimerais débattre un peu sur l'avantage de l'utilisation du test-driven development dans la gestion d'un projet et également avoir un retour d'expériences sur ceux qui l'utilisent déjà.

Est-ce que cela accélère le développement d'une application? Est-ce que son utilisation rend facultatif la modélisation UML avant d'entamer un projet? etc.

Le souci avec les tests unitaires n'est pas exactement un souci mais l'on n'est pas habitué de code un autre code pour tester son code.

J'en profite également pour mettre ce tuto de Bruno Osier pour ceux qui ne connaissement pas le test unitaire: http://bruno-orsier.developpez.com/t...DD/pentaminos/

[souviron34]

Vaste sujet


J'y reviendrais quand j'aurais plus de temps, mais si je peux (extrêmement) résumer ma pensée c'est :

• Ils sont nécessaires (presque) tout le temps
• Leur formalisation ne l'est pas.

Je développerais ultlérieurement ...

[sevyc64]

Perso, je dirais :
- Que les tests sont nécessaires et obligatoires et seront de toute façon faits. Si ce n'est le développeur qui les fait, ça sera le client finale et contre son gré.
- Que Test et Modélisation UML sont 2 choses totalement différentes et indépendantes. Et ce même si les résultats de la modélisation peuvent servir à établir le champs des tests à mettre en place.

Est-ce que les tests unitaires accélère le développement ? Oui et non
- N'a aucune incidence parce que les tests sont normalement codés en parallèle du code normal. Le code normal ne doit pas être développé en fonction des tests, dans l'optique exclusive des tests. A l'exception de la correction des bugs mis en évidence, le code normal ne devrait pas être influencé par le codage des tests.
- Non, ça n'accélère pas le développement, au contraire, si c'est le même développeur qui fait le code normal, et le code de tests. Ça ne va pas intrinsèquement ralentir l'écriture du code normal, mais le temps que le développeur passera à écrire les tests, il ne le passera pas à écrire le code normal. Il faut le prévoir au planning qui sera, de fait plus chargé.
- Oui, ça accélère indirectement le codage, puisque plus tôt le code est testé, plus tôt les bugs sont trouvés et corrigés et moindre sont les conséquences de leurs découvertes. Le deboguage en est facilité et la validation finale plus rapide et plus sure.

Le principe des tests devrait être qu'à partir du moment ou on a du code qui peut être regroupé en une entité autonome et indépendante, cette entité devrait être testée, débuggée et validée dans son fonctionnement.
Par entité, j’entends aussi bien des éléments simples (contrôle, classe, etc) que des éléments plus complexe composés d'entités déjà testées (fonctions, classes, groupement de fonctions, librairies, fonctionnalités, logiciels, etc). Et là, la modélisation, en décrivant l’organisation fonctionnelle du logiciel est une aide pour déterminer quels blocs tester et quand les tester.

[el_slapper]

Les tests unitaires sont obligatoires...et insuffisants.

Obligatoires parceque sans eux, l'homologateur(j'ai eu ce rôle, il y a longtemps) fait face à des horreurs.

Insuffisants parceque certains détails non anticipables sautent aux yeux quand un humain les regarde fonctionner de traviole.

Après, pour leur automatisation, il faut avoir l'environnement pour. Je ne l'ai pas souvent eu. Mais quand c'est possible, c'est très utiles pour les composants isolés. Et surtout, invariants. L'exemple fourni est à ce titre révélateur : on teste un programme qui résoud un problème mathématique. Un pentagramme sera toujours un pentagramme, et si mon élément unitaire fonctionne aujourd'hui, il fonctionnera de toute éternité.

La plupart de mes composants unitaires ont un comportement qui change de mois en mois - parceque le référentiel consultant est lui-même variant. Oui, mais un référentiel spécial test unitaire? Certes, mais il sera factice. Le vrai référentiel de la vraie vie, lui, change sans cesse, et avec lui des cas spéciaux apparaissent et disparaissent. Si on veut tout tester, on a besoin d'un référentiel à l'image de la production. Et donc on ne peut pas automatiser.

A mon sens, le TU, aussi utile soit-il(et Dieu sait qu'il est utile), ne suffit pas. Un regard extérieur(par exemple un homologateur, doublé d'un spécialiste métier) est indispensable pour aller au-delà du bon fonctionnement des composants. Et l'automatisation des tests(unitaires ou de non-regression), c'est très couteux tant que le fonctionnel change.

Franchement, ça doit dépendre du domaine. Pour un truc qui ne doit pas bouger(genre un module de gestion des dates), l'automatisation des TU constitue, à mon sens, un gage de qualité quasiment ultime. Pour un composant qui accède à de nombreux référentiels, à l'architecture mouvante, au fonctionnel encore plus mouvant, c'est un cauchemar garanti.

[souviron34]

• Ils sont nécessaires (presque) tout le temps
• Leur formalisation ne l'est pas.

Je développerais ultlérieurement ...

je vais développer un peu :

Le "presque" que j'inclus dans la première partie est pour des fonctions de base. J'ai toujours trouvé stupide de vouloir/devoir écrire des tests pour des fonctions faisant A+B.. Pour toute fontion un tantinet complexe cependant, cela est nécessaire.

Ensuite, comme le dit sevyc64 :

Ce n'est pas vraiment écrire le test qui est difficile, mais c'est surtout le définir, ce qui doit être testé, comment, dans quelles conditions, ...

Si le nombre de possibilités d'entrées /de sorties / de cas est limité et "circonscrit", un "programme" /fonction de test peut être fait directement.

Si par contre cela est plus vaste, cela devient effectivement une fonctionalité à part entière avant la "cloture" du logiciel.

Après, cela dépend de la structure du soft, de la structure / méthode d'input des données.

Disons que c'est là que se place mon second point.

Je suis absolument contre les recommandations globales et des cycles en V et de certaines méthodologies pour l'écriture systématique et de documents et de tests séparés pour chaque fontionalité : entre perte de temps, génération subsidiaire d'erreurs, non-exhaustivité et lourdeur et de mise en oeuvre et de modification, additioné du sous-entendu de manque de professionalisme des programmeurs, je n'ai jamais adhéré à cette démarche.

Il est cependant nécessaire d'effectuer des tests suffisamment exhaustifs pour vérifier le bon comportement et de la fonctionalité, cela va sans dire, mais aussi de son comportement vis-à-vis de valeurs aberrantes ou aux limites.

Donc, pour l'ensemble du soft, des scénarios sont effectivement nécessaires, y compris via des documentations et des analyses détaillées, ainsi que pour les fonctionalités complexes.

Il est possible, suivant les softs, d'automatiser le déroulement de tout ou partie de ce soft, et donc de ces tests, et dans ce cas les tests "fonctionnels" purs seront bien testés. Cela n'évitera pas cependant de vérifier "à la main" la validité des solutions.. Car on peut parfiatement obtenir quelque chose qui marche sans que cela soit le résultat désiré, et souvent (pas toujours) on n'a pas de "mesures" ou "modélisation" exacte du résultat espéré.

Pour le reste, je préconise plutôt une réflexion style "peer-review" et du code, et de tests, où simplement les styles de cas limites auront été complétés par les experts-utilisateurs (pour isoler des cas qui, bien que incohérents "théroriquement", se passent dans la réalité **).

De toutes façons, tester la validité d'un soft demande du temps et beaucoup de précautions.

Mais je ré-ière mon point que je ne suis pas du tout pour les TU systématiques, et certainement pas pour les TU exhaustifs avec le style de documentation et d'architecture préconisés par les méthodes en V.

Je suis par contre pour un peer-review du code systématique.. quand cela est possible. Et si cela ne l'est pas (par exemple un seul programmeur, ou bien un seul pour cette partie du logicielle), alors un test sytématique (éventuellement par la mise en commentaires de parties de code) de toute fonctionalité un tantinet complexe..


**: note concernant ce point.

J'ai eu le cas, par exemple, pour un logiciel de météo : la physique et ses lois affirment sans ambiguité que l'eau pure gèle à 0 degrés, l'eau salée à -4 degrés, mais que à -53 degrés tout est gelé depuis longtemps. Les modèles numériques de l'atmosphère utilisent donc bien évidemment cette loi. Or il se trouve que ceci est vrai dans une atmosphère stable. La physique et ses lois s'occupent de théorie. Dans la pratique, par exemple au centre des orages ou des ouragans, des courants d'air chaud ascendants peuvent aller très vite et partir quasiment du sol pour monter très haut. Des météorologues m'ont donc singalé que, dans la pratique, il n'était pas très rare que des pilotes leur signalent avoir de l'eau liquide en traversant un nuage à 35 000 pieds (11 km) d'altitude, où la température est de -53... Un logiciel se basant donc juste sur la théorie et ses valeurs numériques ne permettra pas de décrire la réalité... et tout test unitaire ou non n'admettant pas que de l'eau puisse exister à l'état liquide à -53 degré sera faux ..

[slim]

Je suis d'accord avec tous vos messages. Mais...

Il est possible, suivant les softs, d'automatiser le déroulement de tout ou partie de ce soft, et donc de ces tests, et dans ce cas les tests "fonctionnels" purs seront bien testés.

Le point sur lequel je ne suis pas d'accord est qu'il ne faut pas confondre test unitaire et test fonctionnel. On parle bien de TDD et non de ATDD (ou BDD) ?
Il est parfois difficile de faire la différence entre les deux. La frontière est vite dépassée. On retrouve souvent des tests unitaires qui testent des fonctionnalités et non des méthodes d'un programme.

Les tests unitaires ne doivent pas tester des fonctionnalités.

[souviron34]

Le point sur lequel je ne suis pas d'accord est qu'il ne faut pas confondre test unitaire et test fonctionnel. On parle bien de TDD et non de ATDD (ou BDD) ?

je suis d'accord. Ce que je voulais dire, c'est que il peut exister des softs pur lesquels la séparation de toutes les fonctions (TU) est aisément programmable/settable par un programme test ou appelant. auquel cas un TU généralisé et automatisable facilement. (par exemple un "moteur' avec un langage de commandes)

[slim]

Bonjour,

J'ai participé à un assez gros projet pendant 3 ans en tant que développeur. On utilisait le TDD mais pas vraiment. La méthode implique l'écriture des tests avant le développement, mais rares sont les personnes qui le font. Généralement, les tests sont écrits par la suite.
Malgré cela, 70% de l'application était couverte par les tests. Cela garantissait réellement la robustesse du code, la non régression etc.

Est-ce que cela accélère le développement d'une application?

Non à court terme. Le développement d'une fonctionnalité prendra un petit peu plus de temps que si l'on développait sans TU (Il faut bien du temps pour les développer). Mais à long terme, il est évident que le développement est beaucoup plus rapide et l'étape de debug de code est plus courte.

Le souci avec les tests unitaires n'est pas exactement un souci mais l'on n'est pas habitué de code un autre code pour tester son code.

Les reponsables de projets et même les développeurs n'ont pas forcément conscience de l'avantage des TU. Mais ils représentent une réelle plus-value. Ces tests, quand ils sont correctement utilisés, peuvent représenter une spécification et un bon point de départ pour le développement. De plus, ils sont assez simples à implémenter : un test est un peu stupide (Arrange - Action - Assert : Initialisation - Action - Vérification).

Je dirais aussi que le temps passé sur l'implémentation des fonctionnalités est moins important, la conception est meilleure et c'est très motivant pour les développeurs.
C'est aussi un gage de qualité du logiciel !

Dans le cycle de développement, si mon test passe au vert et si je procède à un refactoring, tant que le TU est au rouge, je sais que mon refactoring n'est pas bon. Celui-ci est donc cadré.

Est-ce que son utilisation rend facultatif la modélisation UML avant d'entamer un projet?

Je ne pense pas que la modélisation des uses case ou des états-transitions etc. ait un lien avec les tests unitaires. Ces tests sont structurels et non fonctionnels.
Ce qui rendrait ces diagrammes facultatifs, ce sont les tests fonctionnels automatisés.
Durant le projet sur lequel je travaillais, nous n'avions que le modèle de données. Nous n'avions aucun modèle UML et c'est un outil de tests fonctionnels qui compensait...

Franchement, ça doit dépendre du domaine. Pour un truc qui ne doit pas bouger(genre un module de gestion des dates), l'automatisation des TU constitue, à mon sens, un gage de qualité quasiment ultime. Pour un composant qui accède à de nombreux référentiels, à l'architecture mouvante, au fonctionnel encore plus mouvant, c'est un cauchemar garanti.

La réponse à ta dernière phrase serait justement les tests fonctionnels automatisés. Avec un tel outil, ce n'est vraiment plus un cauchemar, car ces tests peuvent couvrir tout le périmètre fonctionnel du logiciel et évoluer avec.

[randriano]

En lançant ce petit débat, je savais qu'il y a des atouts et des inconvénients pour les tests unitaires comme toute technique.

Souvent, c'est le développeur qui a écrit le programme qui écrit le code de test non? Ce que j'essaie de comprendre c'est comment un développeur qui vient de découvrir ce type de test pourra appréhender rapidement sa philosophie mais on sait tous le résultat d'après: un code sûr.

Écrire un code de test n'est pas si facile que ça en a l'air: imaginons un code de test unitaire d'un jeu de labyrinthe ... !!

[slim]

Souvent, c'est le développeur qui a écrit le programme qui écrit le code de test non?

Oui, forcément. Mais un autre développeur peut tout à fait écrire le test aussi...

Ce que j'essaie de comprendre c'est comment un développeur qui vient de découvrir ce type de test pourra appréhender rapidement sa philosophie

En lisant la doc de la librairie de test utilisée et quelques docs sur internet : comme ici.

Écrire un code de test n'est pas si facile que ça en a l'air: imaginons un code de test unitaire d'un jeu de labyrinthe ... !!

Ce programme doit comporter plusieurs méthodes. On ne met pas un test pour tout le programme mais pour chaque méthode.
C'est pour cela que ce sont des tests unitaires.

[sevyc64]

Souvent, c'est le développeur qui a écrit le programme qui écrit le code de test non?

Idéalement Non !

Dans l'idéal, l'équipe des codeurs des tests devrait être totalement indépendante de celle qui code le logiciel. Elle ne devrait pas participer au codage du logiciel.
Mais ça nécessite beaucoup de ressources humaines et donc coute cher. Une position intermédiaire consiste à confier le codage des tests à tout ou partie des codeurs du logiciel. Ils codent alors les tests pour des parties du logiciel dont ils n'ont pas la charge du codage.

Mais dans la réalité, c'est bien souvent le même codeur qui code, à la fois le logiciel et les tests qui vont le tester. Avec le risque important que les tests codés soient influencés par le code réalisé et qui est à tester, avec le risque d'une moindre pertinence des tests et des cas oubliés, etc.

Écrire un code de test n'est pas si facile que ça en a l'air: imaginons un code de test unitaire d'un jeu de labyrinthe ... !!

Ce n'est pas vraiment écrire le test qui est difficile, mais c'est surtout le définir, ce qui doit être testé, comment, dans quelles conditions, ...

Il y a des tests qui font partie de la base : 2-3 valeurs significatives, les cas particuliers, les tests aux limites (de chaque coté des limites), etc..

Par exemple, une fonction qui reçoit en paramètre un n° de département français, tu va tester 2-3 n° corrects, tu vas tester les n° 00, 01, 97, 98 par exemple (les limites), tu vas tester un n° sur 3 chiffres (n° hors limite mais aussi cas particulier de 3 chiffres au lieu de 2).
Suivant comment est codé ta fonction, tu peux aussi tester le cas d'un n° à 1 chiffre représenté sur 2 chiffres, par exemple, 2 et 02 (cf FreeMobile et son bug des codes postaux pour envoyer les cartes SIM), etc...

[el_slapper]

(.../...sur les tests automatisés sur une interface mouvante)

La réponse à ta dernière phrase serait justement les tests fonctionnels automatisés. Avec un tel outil, ce n'est vraiment plus un cauchemar, car ces tests peuvent couvrir tout le périmètre fonctionnel du logiciel et évoluer avec.

Je ne suis pas d'accord(mais on a pas forcément exactement bossé sur les mêmes sujets, et dans les mêmes conditions). Quand le comportement global d'un bloc global est altéré, adapter tous les tests automatiques peut virer au cauchemar.

Un petit bloc simple, il bouge, on fait bouger son test, tout va bien. Le test global, lui, aura complètement autre chose, et on est bon pour tout refaire. Dans mon domaine précis, c'est la règle plutôt que l'exception. Il n'est alors pas rentable de faire un test automatique.

Sinon, globalement d'accord pour le reste. Ecrire les TU en fonction des specs, d'accord. Ecrire des specs de TU en fonction des specs, puis les implémenter sans se poser de questions, pas d'accord. D'ailleurs, souvent, les gens écrivent les TU après parcequ'une fois la fonction codée, ils voient mieux ce qu'il faut faire.

Et j'insiste aussi sur les conditions de travail. Une banque ou j'ai jadis bossé avait un environnement de dev sans référentiel adapté, et un environnement d'homologation blindé contre les softs de test automatique. Moralité, les TU en test tournaient en bouchonné(pas terrible), et il m'était impossible d'automatiser mes tests d'interface en homologation. Quand on est maitre de son environnement, qu'on peut à loisir mettre en place un référentiel à notre main, et que notre poste de travail n'est pas verrouillé, on peut faire des choses formidables. Sinon.....

[slim]

Un petit bloc simple, il bouge, on fait bouger son test, tout va bien. Le test global, lui, aura complètement autre chose, et on est bon pour tout refaire.

Justement, ce test global n'est pas unitaire. Par exemple, la fonction qui représente le point d'entrée d'une fonctionnalité n'est pas testée unitairement mais testée avec un outil de tests fonctionnels automatisés.

[sevyc64]

Un petit bloc simple, il bouge, on fait bouger son test, tout va bien. Le test global, lui, aura complètement autre chose, et on est bon pour tout refaire.

Justement, le petit bloc bouge, donc son test bouge pour à nouveau valider son fonctionnement.

Ensuite, soit l'altération du petit provoque une modification du fonctionnement des plus gros blocs l'utilisant, dans ce cas les tests de ces gros blocs doivent aussi bouger. Soit cette altération ne modifie pas le fonctionnement des gros blocs, à ce moment là, les tests ne doivent surtout pas être modifiés mais continuer à valider le fonctionnement du gros bloc, malgré qu'un des composant est changé.

Bien entendu, cela signifie que le test d'un gros bloc ne teste que les fonctionnalités propre à ce gros bloc, et ne va pas tester les fonctionnalités spécifiques des blocs plus petits qui pourraient le composer.

Par exemple, le test d'un bloc de calcul de moyenne ne doit tester que le calcul de la moyenne elle-même. Il ne doit pas aller tester l'addition et la division sous-jacente réalisées par des sous-blocs correspondants, eux-même déjà tester par leurs propres tests.
Dans ce cas, on pourra très bien modifier le sous bloc Addition et donc son test, sans pour autant toucher au bloc Moyenne que son test, qui ne doit pas être non plus modifié, continuera à valider.

[randriano]

Voici un article qui ne parle pas de test unitaire au départ mais qui m'a permis à comprendre un peu plus: http://rad-hass.developpez.com/tutor...our-experience

Le TDD implique un changement de mentalité, le pratiquer demande une certaine rigueur. Au départ, c'est déroutant et il faut un certain temps pour l'assimiler. Souvent au départ le rejet est fort on ne se rend pas toujours compte de la difficulté. Il faut préparer son monde car intégrer TDD dans son développement n'est pas toujours simple ...

[gangsoleil]

l'avantage de l'utilisation du test-driven development

[...]
Le souci avec les tests unitaires [..]

Attention a ne pas confondre TDD et tests unitaires.

Un test unitaire, c'est le fait d'ecrire un test qui (in)valide une fonction de base de ton code, mais ca ne suppose en rien de la methodologie utilisee : on trouve des tests unitaire dans le cycle en V, en Scrum/agile/buzz-word-a-la-mode, dans la methode de la rache si on a un peu de temps, ...

[slim]

+1 !!

Je suis complétement d'accord. Mais je pense aussi que les gens qui utilisent sérieusement la méthodologie sont rares... Même dans un processus de TDD, généralement, les tests sont écrits après le code. D'après mon expérience...

J'étais dans une équipe où le code était couvert à 65-70 % (ou plus je sais plus ) par les tests. Toute la sauce y était : SCRUM, tests fonctionnels automatisés, TDD...
Personne ne les écrivait avant et on disait qu'on faisait du TDD .

[slim]

Juste un petit truc en plus.

Je serais pour changer le terme TDD et le remplacer par TMD (Test Management Driven) parce que le plus important à mon avis et "l'analyse" et la conduite de projet par les tests. Après pour le développement, l'essentiel est qu'il y en ait.

[souviron34]

Bah dans cette veine ça devrait alors être soit TME soit TMS

Test Management Eviction ou Test Management Selection



Tu fais un projet qui foire, bye bye

[sevyc64]

Tu fais un projet qui foire, tu es le maillon failble, bye bye