Pourquoi j'ai abandonné les tests automatiques

[kisitomomotene]

Salut à tous

j'ai achevé un projet de développement d'une application et j'aimerais commenter l'expérience que j'ai eu concernant particulièrement les tests.
- Au début du développement, j'effectuais des tests pour toutes les spécifications et fonctionnalités que je développais,

- le développement de ces tests me prenait un temps non négligeable et surtout lorsque un test échouait très souvent en débuggant, je trouvait que l'erreur se trouvait plutôt dans le code du test et non dans le code de la fonctionnalité testée.

- Ensuite il arrivait parfois que, après avoir effectué un test automatique, lorsque j'effectuait le même test manuellement comme un véritable utilisateur, je découvrais certaine erreur qui n'avait pas été détectée par le test automatique correspondant ( dû au fait que l'environnement du test automatique, bien que en principe devrait simuler parfaitement l'environnement du test utilisateur, comportait en réalité certaine différence qui causait des disparités au niveau du résultat de certain test). Donc les tests automatiques ne m'épargnaient pas d'effectuer les tests manuels d'où une perte de temps presque inutile

- Enfin comme les spécifications et la conception de l'application changeaient à une fréquence relativement élevée, les tests écrits ainsi avec trop de peines et de coût en temps de développement devenaient tout aussi obsolètes très tôt sans pouvoir jouer leur rôle anti-régressif.

- Finalement les dernière itérations de mon application ont été faites sans l'écriture des tests automatiques

[souviron34]

bienvenue dans le monde réel

De la différence entre la théorie et la pratique ...

(ce que je maintiens , tout en me faisant régulièrement jeter)...

[dba01]

Rien de tel qu'un véritable utilisateur pour tester les écrans.
Ils ont une imagination qui m'a toujours étonné.

[el_slapper]

Je ferais une réponse d'ingénieur : ça dépend.

Dans de nombreux cas, je suis d'accord avec le posteur initial. Maintenant, quand on a une appli devenue assez stable, mais qui subit régulièrement de petites évolutions, un test de non-régréssion automatique peut être bien utile. Ce qui a été validé une fois, l'humain a tendance, inconsciemment, à le considérer valide pour toujours.

Sinon, j'ai fait un projet de refonte d'un code de 36 ans d'âge(plus que mon âge à l'époque). Ca générait un fichier pour une édition de courriers clients, pour les vieilles imprimantes. Que je devais remplacer par la génération d'un fichier pour Doc1(en XML). Mais le vieux code était illisible, et les doc avaient disparu depuis fort, fort longtemps. Seule solution pour valider mon code : comparer.

Comparer, champ fonctionnel par champ fonctionnel, sachant que chacun des 2 flux avait pas mal de sucre technique autour(juste pas du tout le même sucre); j'avais codé la solution initiale assez au pif(en fonction de ce que j'avais compris d'un existant assez illisible), et j'ai eu à peu près autant d'erreurs dans mon code de solution que dans mon code de comparaison

Le plus drôle : après presque deux mois d'efforts acharnés, il n'est resté qu'un seul écart : la nouvelle chaine donnait échéance le 30 Juin/Septembre, l'ancienne le 31 Juin/Septembre.....Celui-là, on l'a laissé, bizarrement

Donc, oui, un code de test est long et difficille à écrire, avec pas mal d'erreurs. Si c'est pour le bousculer sans cesse, ça ne vaut pas le coup. Ce qui est parfois le cas, parfois non.

[Richard_35]

Bonjour à tous,

Je ne pense pas que ce soit le principe des tests qui est en cause, mais l'organisation d'un projet de développement en général, quelque soit son importance.

Dans le cas présenté par Kisitomomotene, il semblerait que personne (côté "utilisateurs"), ne se soit jamais engagé sur rien !... dans ce cas, il est facile (côté "utilisateurs") de considérer que tout ce qui a été développé est normal/évident et tout ce qui "manque" (du point de vue "utilisateurs") constitue un scandale planétaire !...

En bref, dans notre job (comme dans d'autres), il existe deux "modes" :

• le mode "guichet" (requête ponctuelle simple, etc...) ;
• le mode "projet" (application à développer, etc...).

C'est vrai que la frontière est un peu plus épaisse qu'une lame de rasoir mais, 95% des cas sont facilement classables.


Passer une tâche d'un côté, alors qu'elle devrait être de l'autre s'avère très risqué :

• tâche "guichet" en mode "projet" : ralentissement inutile d'un développement simple ;
• tâche "projet" en mode "guichet" : développement sans trop d'analyse, aller/retour permanent entre utilisateurs et développeurs, etc...

Kisitomomotene semble avoir travaillé sur un "projet" en mode "guichet" (et doit continuer à tester ses aplpications...).