Discussion :

[kisitomomotene]

Salut à tous.

J'ecrit une application actuellement, et je constate que l'ecriture des programmes de test me prend trop de temps, car je developpe en utilisant en framework, et pour effectuer les tests il faut recréer l'environnement, et un context d'execution du framework spécifique à ce que je dois tester, et ceci par programmation. Ce qui fait que je passe plus de temps à deboguer mes programmes de tests qu'à déboguer mon application elle même. Quelqu'un c'est il dejà trvé dans cette situation?

[pseudocode]

Quelqu'un c'est il dejà trvé dans cette situation?

Oui, tres souvent. D'apres ce que j'ai observé, le probleme vient souvent du type de test réalisés. Ils sont généralement trop gros/complexes comparativement au type d'activité de développement.

1ere chose a faire: définir les types de test que vous voulez faire en fonction de vos activités de développement.

Dans un cycle de développement "habituel", on sépare les activités de codage "unitaire", d'"integration" et de "validation"

Le codage "unitaire" est la réalisation d'un objet (=composant) autonome. Bon, l'autonomie complete n'existe generalement pas: le composant a besoin de "services externes" pour fonctionner. Lors des tests "unitaires", on remplacera le vrai "service externe" par un bouchon/simulateur.

Il convient d'avoir une conception qui permette de faire cela facilement. En objet, on utilise des interfaces vers les "services externes". Cela permet de changer facilement l'implémentation du service (réel, bouchon, simulateur, ...) sans changer le code du composant

L' "integration" consiste a assembler les composants entre eux. C'est a dire spécifier, pour chaque composant, l'implémentation des autres composants dont il a besoin. Lors des tests d'"integration", on commence par assembler quelques "vrais" composants (2, 3, ...), puis on remet les bouchons partout ailleur. Si les tests sont concluant, on peut étendre le nombre de "vrais" composants a tester.

Enfin la "validation", qui consiste a tester "en boire noire" l'integralité du logiciel. Ce sont ces tests la qui sont les plus couteux en temps (d' ecriture et d'execution)

Généralement, on a tendance a faire des tests de "validation" trop tot. Comme le logiciel n'est pas encore fini, il y a des bouchons partout afin d'avoir une maquette fonctionnelle utilisable. Au fur et a mesure que le logicel evolue, on doit alors modifier/refaire de nouveaux bouchons... Bref, on passe plus de temps a réécrire les bouchons qu'a développer le logiciel.

Donc, en conclusion, je vous conseille de commencer les tests de "validation" lorsque le logiciel est (quasi) complet. C'est a dire que tous les composants sont testés unitairements et integrés. Pour cela, n'hesitez pas a ecrire beaucoup de tests unitaires+integrations. Ces tests sont generalement simples a ecrire, et leur déroulement est automatisable. Tout bug trouvé lors de ces tests est (au moins) un bug de moins en validation !

[dracosire]

Il faut aussi savoir qu'il est difficile de trouver ses erreurs dans son propre code, surtout quand on pense qu'il est bon !

En tant que testeur, j'ai déjà constaté que souvent les développeurs évitent instinctivement leurs propres bugs lors de tests.

Il vont d'abord tester les parties dont ils sont sûrs.

Si tu en a la possibilitée, il est préférable de demander à quelqu'un d'autre de tester tes modules.