Bonjour, en mettant au point certains tests unitaires avec JUnit je me
rends compte que pour certains d'entre eux le nombre de paramètres et donc
de combinaisons à tester est trop important pour pouvoir être effectués à
la main...
Dans un bouquin j'ai entendu parler du concept des "oracles de tests" mais
sans plus de précisions. J'ai tenté quelques recherche sur Google mais avec
le terme "oracle" je ne tombe que sur des articles en rapport avec la bd du
même nom.
Est-ce que quelqu'un pourrait me donner quelques pistes ?
Dans un bouquin j'ai entendu parler du concept des "oracles de tests" mais sans plus de précisions.
Ce n'est ni plus ni moins que la notion de comparer ce qu'on obtient en sortie d'un cas de test avec un résultat attendu. Un assertEquals() c'est un oracle de test. Il doit y en avoir pas mal, des développeurs qui comme Monsieur Jourdain font des oracles de test sans le savoir. :)
Bonjour, en mettant au point certains tests unitaires avec JUnit je me rends compte que pour certains d'entre eux le nombre de paramètres et donc de combinaisons à tester est trop important pour pouvoir être effectués à la main...
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut t'aider, mais c'est difficile à dire avec la description ci-dessus...
Pour "all pairs" voir l'article de mon ami Michael Bolton: http://www.developsense.com/testing/PairwiseTesting.html
Laurent
J'ai tenté quelques recherche sur Google mais avec le terme "oracle" je ne
tombe que sur des articles en rapport avec la bd du même nom.
Google "test oracle" (la traduction de "oracle de test") pointe par
exemple sur l'article suivant:
Dans un bouquin j'ai entendu parler du concept des "oracles de tests" mais
sans plus de précisions.
Ce n'est ni plus ni moins que la notion de comparer ce qu'on obtient en
sortie d'un cas de test avec un résultat attendu. Un assertEquals()
c'est un oracle de test. Il doit y en avoir pas mal, des développeurs
qui comme Monsieur Jourdain font des oracles de test sans le savoir. :)
Bonjour, en mettant au point certains tests unitaires avec JUnit je me
rends compte que pour certains d'entre eux le nombre de paramètres et donc
de combinaisons à tester est trop important pour pouvoir être effectués à
la main...
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut
t'aider, mais c'est difficile à dire avec la description ci-dessus...
Pour "all pairs" voir l'article de mon ami Michael Bolton:
http://www.developsense.com/testing/PairwiseTesting.html
Dans un bouquin j'ai entendu parler du concept des "oracles de tests" mais sans plus de précisions.
Ce n'est ni plus ni moins que la notion de comparer ce qu'on obtient en sortie d'un cas de test avec un résultat attendu. Un assertEquals() c'est un oracle de test. Il doit y en avoir pas mal, des développeurs qui comme Monsieur Jourdain font des oracles de test sans le savoir. :)
Bonjour, en mettant au point certains tests unitaires avec JUnit je me rends compte que pour certains d'entre eux le nombre de paramètres et donc de combinaisons à tester est trop important pour pouvoir être effectués à la main...
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut t'aider, mais c'est difficile à dire avec la description ci-dessus...
Pour "all pairs" voir l'article de mon ami Michael Bolton: http://www.developsense.com/testing/PairwiseTesting.html
Laurent
Zouplaz
Laurent Bossavit - :
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut t'aider, mais c'est difficile à dire avec la description ci-dessus...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après chaque exécution l'état attendu du registre d'état. En bref, ça signifie écrire des centaines de lignes de tests (et encore, c'est un cpu plutôt simple) avec le risque d'en oublier quelques uns au passage...
Dans un cas comme celui là, je sens que l'automatisation des tests à partir d'une matrice serait plus simple (état initial, paramètres à modifier, résultat attendu) conçu avec une autre appli (question lisibilité) et exportée à un format quelconque (xml ?)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de test, comment on les formalise ? le problème c'est pas tant imaginer la mise en oeuvre au niveau de JUnit mais plutôt la logique qui se cache dans la conception et la formalisation de cette matrice de tests...
Bon, il est plutôt tard suis pas sûr d'être très clair ;-)
Laurent Bossavit - laurent@dontspambossavit.com :
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut
t'aider, mais c'est difficile à dire avec la description ci-dessus...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un
ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui
est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois
pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après
chaque exécution l'état attendu du registre d'état. En bref, ça signifie
écrire des centaines de lignes de tests (et encore, c'est un cpu plutôt
simple) avec le risque d'en oublier quelques uns au passage...
Dans un cas comme celui là, je sens que l'automatisation des tests à partir
d'une matrice serait plus simple (état initial, paramètres à modifier,
résultat attendu) conçu avec une autre appli (question lisibilité) et
exportée à un format quelconque (xml ?)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de
test, comment on les formalise ? le problème c'est pas tant imaginer la
mise en oeuvre au niveau de JUnit mais plutôt la logique qui se cache dans
la conception et la formalisation de cette matrice de tests...
Bon, il est plutôt tard suis pas sûr d'être très clair ;-)
Tu peux en dire plus ? Peut-être que la technique "all pairs" peut t'aider, mais c'est difficile à dire avec la description ci-dessus...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après chaque exécution l'état attendu du registre d'état. En bref, ça signifie écrire des centaines de lignes de tests (et encore, c'est un cpu plutôt simple) avec le risque d'en oublier quelques uns au passage...
Dans un cas comme celui là, je sens que l'automatisation des tests à partir d'une matrice serait plus simple (état initial, paramètres à modifier, résultat attendu) conçu avec une autre appli (question lisibilité) et exportée à un format quelconque (xml ?)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de test, comment on les formalise ? le problème c'est pas tant imaginer la mise en oeuvre au niveau de JUnit mais plutôt la logique qui se cache dans la conception et la formalisation de cette matrice de tests...
Bon, il est plutôt tard suis pas sûr d'être très clair ;-)
Laurent Bossavit
Je copie et redirige vers fr.comp.developpement, tout ça va au-delà de Java...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après chaque exécution l'état attendu du registre d'état.
Projet sympa! Ah, mes débuts sur Apple II (enfin, pas tout à fait mes débuts, il y a eu l'époque ZX81...) que des projets de ce genre m'ont permis de redécouvrir avec nostalgie...
Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs
Pourquoi ?
Dans le test comme dans le code, la voie pour maîtriser la complexité c'est de factoriser ce qui peut l'être. Dans "ce qui peut l'être" il y a évidemment une certaine science, mais on peut procéder empiriquement aussi.
Concrètement, "all pairs" devrait être indiqué pour croiser opcodes et modes d'adressage. Si tes méthodes de calcul des adresses effectives sont bonnes pour un opcode, il n'y a pas de raison qu'elles soient fausses pour les autres.
Quel est l'objectif de tes tests unitaires ?
Dans un cas comme celui là, je sens que l'automatisation des tests à partir d'une matrice serait plus simple (état initial, paramètres à modifier, résultat attendu) conçu avec une autre appli (question lisibilité) et exportée à un format quelconque (xml ?)
Pour paraphraser une citation célebre:
Parfois, confronté à un problème, tu penses "Ah oui, je vais utiliser XML". Maintenant tu as deux problèmes.
;-)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de test, comment on les formalise ? le problème c'est pas tant imaginer la
Un peu de lecture préliminaire: http://www.pnsqc.org/files/FourSchoolsofSoftwareTesting.pdf http://www.kohl.ca/blog/archives/000087.html http://testingeducation.org/conference/wtst_pettichord_UTST.pdf
Pour aller plus loin: http://www.amazon.fr/exec/obidos/ASIN/0471081124/ (je l'ai lu et le recommande) http://www.amazon.fr/exec/obidos/ASIN/0201809389/ (je ne l'ai pas lu, mais c'est une référence)
Laurent
Je copie et redirige vers fr.comp.developpement, tout ça va au-delà de
Java...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un
ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui
est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois
pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après
chaque exécution l'état attendu du registre d'état.
Projet sympa! Ah, mes débuts sur Apple II (enfin, pas tout à fait mes
débuts, il y a eu l'époque ZX81...) que des projets de ce genre m'ont
permis de redécouvrir avec nostalgie...
Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent
être exhaustifs
Pourquoi ?
Dans le test comme dans le code, la voie pour maîtriser la complexité
c'est de factoriser ce qui peut l'être. Dans "ce qui peut l'être" il y a
évidemment une certaine science, mais on peut procéder empiriquement
aussi.
Concrètement, "all pairs" devrait être indiqué pour croiser opcodes et
modes d'adressage. Si tes méthodes de calcul des adresses effectives
sont bonnes pour un opcode, il n'y a pas de raison qu'elles soient
fausses pour les autres.
Quel est l'objectif de tes tests unitaires ?
Dans un cas comme celui là, je sens que l'automatisation des tests à partir
d'une matrice serait plus simple (état initial, paramètres à modifier,
résultat attendu) conçu avec une autre appli (question lisibilité) et
exportée à un format quelconque (xml ?)
Pour paraphraser une citation célebre:
Parfois, confronté à un problème, tu penses "Ah oui, je vais utiliser
XML". Maintenant tu as deux problèmes.
;-)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de
test, comment on les formalise ? le problème c'est pas tant imaginer la
Un peu de lecture préliminaire:
http://www.pnsqc.org/files/FourSchoolsofSoftwareTesting.pdf
http://www.kohl.ca/blog/archives/000087.html
http://testingeducation.org/conference/wtst_pettichord_UTST.pdf
Pour aller plus loin:
http://www.amazon.fr/exec/obidos/ASIN/0471081124/
(je l'ai lu et le recommande)
http://www.amazon.fr/exec/obidos/ASIN/0201809389/
(je ne l'ai pas lu, mais c'est une référence)
Je copie et redirige vers fr.comp.developpement, tout ça va au-delà de Java...
Voila ce qui se passe : à temps perdu (!) je me suis amusé à reprendre un ancien projet qui consiste à émuler un cpu 8 bits. Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs : je dois pouvoir tester chaque opcode pour chaque mode d'adressage et vérifier après chaque exécution l'état attendu du registre d'état.
Projet sympa! Ah, mes débuts sur Apple II (enfin, pas tout à fait mes débuts, il y a eu l'époque ZX81...) que des projets de ce genre m'ont permis de redécouvrir avec nostalgie...
Le problème, pour ce qui est des tests unitaires, c'est qu'il doivent être exhaustifs
Pourquoi ?
Dans le test comme dans le code, la voie pour maîtriser la complexité c'est de factoriser ce qui peut l'être. Dans "ce qui peut l'être" il y a évidemment une certaine science, mais on peut procéder empiriquement aussi.
Concrètement, "all pairs" devrait être indiqué pour croiser opcodes et modes d'adressage. Si tes méthodes de calcul des adresses effectives sont bonnes pour un opcode, il n'y a pas de raison qu'elles soient fausses pour les autres.
Quel est l'objectif de tes tests unitaires ?
Dans un cas comme celui là, je sens que l'automatisation des tests à partir d'une matrice serait plus simple (état initial, paramètres à modifier, résultat attendu) conçu avec une autre appli (question lisibilité) et exportée à un format quelconque (xml ?)
Pour paraphraser une citation célebre:
Parfois, confronté à un problème, tu penses "Ah oui, je vais utiliser XML". Maintenant tu as deux problèmes.
;-)
Et la question est (ta ta tan !) : où trouver de la théorie sur ce genre de test, comment on les formalise ? le problème c'est pas tant imaginer la
Un peu de lecture préliminaire: http://www.pnsqc.org/files/FourSchoolsofSoftwareTesting.pdf http://www.kohl.ca/blog/archives/000087.html http://testingeducation.org/conference/wtst_pettichord_UTST.pdf
Pour aller plus loin: http://www.amazon.fr/exec/obidos/ASIN/0471081124/ (je l'ai lu et le recommande) http://www.amazon.fr/exec/obidos/ASIN/0201809389/ (je ne l'ai pas lu, mais c'est une référence)
