suite à une autre discussion qui a dérivé, j'aurais aimé savoir
comment vous faites vos tests unitaires, avec quoi, quels outils
et quelle méthodologie ?
Merci d'avance,
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent Deniau
Marc Boyer wrote:
Bonjour,
suite à une autre discussion qui a dérivé, j'aurais aimé savoir comment vous faites vos tests unitaires, avec quoi, quels outils et quelle méthodologie ?
Merci d'avance, Marc Boyer
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name). execute *un* test de la classe de test base sur son nom - run(void) execute tous les tests de la classe de test, c'est a dire les methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de la classe de test qui derive de TestCase et retournent un TestResult (une sorte de rapport).
et deux methodes de pre/post init/deinit
- setup appellee avant chaque test - cleanup appellee apres chaque test
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Bref une copie de JUnit mais en C90 (OOC-2.0), environ 800 lignes de code C. Ca m'est apparu rapidement indispensable.
a+, ld.
Marc Boyer wrote:
Bonjour,
suite à une autre discussion qui a dérivé, j'aurais aimé savoir
comment vous faites vos tests unitaires, avec quoi, quels outils
et quelle méthodologie ?
Merci d'avance,
Marc Boyer
Je derive de TestCase pour les classes de test et j'utilise TestSuite
pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name).
execute *un* test de la classe de test base sur son nom
- run(void)
execute tous les tests de la classe de test, c'est a dire les
methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de
la classe de test qui derive de TestCase et retournent un TestResult
(une sorte de rapport).
et deux methodes de pre/post init/deinit
- setup
appellee avant chaque test
- cleanup
appellee apres chaque test
L'interet c'est que TestCase bloque les exceptions et fait un rapport
(TestResult et TestFailure) sur quel test+condition+file+line il s'est
arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la
classe en cours mais ne stoppe pas toute la suite.
Bref une copie de JUnit mais en C90 (OOC-2.0), environ 800 lignes de
code C. Ca m'est apparu rapidement indispensable.
suite à une autre discussion qui a dérivé, j'aurais aimé savoir comment vous faites vos tests unitaires, avec quoi, quels outils et quelle méthodologie ?
Merci d'avance, Marc Boyer
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name). execute *un* test de la classe de test base sur son nom - run(void) execute tous les tests de la classe de test, c'est a dire les methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de la classe de test qui derive de TestCase et retournent un TestResult (une sorte de rapport).
et deux methodes de pre/post init/deinit
- setup appellee avant chaque test - cleanup appellee apres chaque test
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Bref une copie de JUnit mais en C90 (OOC-2.0), environ 800 lignes de code C. Ca m'est apparu rapidement indispensable.
a+, ld.
Marc Boyer
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name). execute *un* test de la classe de test base sur son nom - run(void) execute tous les tests de la classe de test, c'est a dire les methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de la classe de test qui derive de TestCase et retournent un TestResult (une sorte de rapport).
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
OK
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite
pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name).
execute *un* test de la classe de test base sur son nom
- run(void)
execute tous les tests de la classe de test, c'est a dire les
methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de
la classe de test qui derive de TestCase et retournent un TestResult
(une sorte de rapport).
Donc ça, ça sert à lancer tous les tests de la classe de test.
Mais les tests de la classe de tests, tu les écris à la main
individuellement ?
L'interet c'est que TestCase bloque les exceptions et fait un rapport
(TestResult et TestFailure) sur quel test+condition+file+line il s'est
arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la
classe en cours mais ne stoppe pas toute la suite.
OK
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
- runTest(const char *name). execute *un* test de la classe de test base sur son nom - run(void) execute tous les tests de la classe de test, c'est a dire les methodes de la classe dont le nom commence par "test".
Les deux methodes utilisent la reflection pour trouver les methodes de la classe de test qui derive de TestCase et retournent un TestResult (une sorte de rapport).
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
OK
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Marc Boyer
Laurent Deniau wrote:
Marc Boyer wrote:
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des unit tests?
Non, pas vraiment. je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage) ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework" qui me posait question. Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous les tests de la classe de test (celle qui derive de TestCase), cleanup (tearDown en Java je crois) pour nettoyer tout ce que le dernier test execute a pu laisser comme ressources non liberees et testAssert pour valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL) test unitaire = methode qui teste une fonctionalite,e.g. testStringCat() TestCase = groupe de test unitaire, e.g. TestString : TestCase TestSuite = suite de groupe de test, e.g. TestString, TestArray dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux macro (le testAssert) et en appellant le reste à la main depuis un main.
par des tests qui ratent expres (perso je zappe souvent cette etape) pour valider le test lui-meme.
OK
Puis on perfectionne le test en lui ajoutant des cas a traiter. Un test doit rester simple et "stupide" pour etre comprehensible immediatement (1ere lecture) et ne pas perdre de temps a l'ecrire. Il peut eventuellement servir de doc.
Ha... Mes tests sont simple, stupides, mais de là à servir de doc.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye jouer ailleurs ;-)
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Laurent Deniau wrote:
Marc Boyer wrote:
Donc ça, ça sert à lancer tous les tests de la classe de test.
Mais les tests de la classe de tests, tu les écris à la main
individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des
unit tests?
Non, pas vraiment.
je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage)
ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de
suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework"
qui me posait question.
Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB
sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous
les tests de la classe de test (celle qui derive de TestCase), cleanup
(tearDown en Java je crois) pour nettoyer tout ce que le dernier test
execute a pu laisser comme ressources non liberees et testAssert pour
valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL)
test unitaire = methode qui teste une fonctionalite,e.g. testStringCat()
TestCase = groupe de test unitaire, e.g. TestString : TestCase
TestSuite = suite de groupe de test, e.g. TestString, TestArray
dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque
modification "significative" du code pour valider que tout continue a
fonctionner correctement selon le protocol de test. C'est pour eviter
une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux
macro (le testAssert) et en appellant le reste à la main depuis un main.
par des tests qui ratent expres (perso je zappe souvent cette etape)
pour valider le test lui-meme.
OK
Puis on perfectionne le test en lui
ajoutant des cas a traiter. Un test doit rester simple et "stupide" pour
etre comprehensible immediatement (1ere lecture) et ne pas perdre de
temps a l'ecrire. Il peut eventuellement servir de doc.
Ha... Mes tests sont simple, stupides, mais de là à servir de doc.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne
parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye
jouer ailleurs ;-)
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des unit tests?
Non, pas vraiment. je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage) ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework" qui me posait question. Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous les tests de la classe de test (celle qui derive de TestCase), cleanup (tearDown en Java je crois) pour nettoyer tout ce que le dernier test execute a pu laisser comme ressources non liberees et testAssert pour valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL) test unitaire = methode qui teste une fonctionalite,e.g. testStringCat() TestCase = groupe de test unitaire, e.g. TestString : TestCase TestSuite = suite de groupe de test, e.g. TestString, TestArray dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux macro (le testAssert) et en appellant le reste à la main depuis un main.
par des tests qui ratent expres (perso je zappe souvent cette etape) pour valider le test lui-meme.
OK
Puis on perfectionne le test en lui ajoutant des cas a traiter. Un test doit rester simple et "stupide" pour etre comprehensible immediatement (1ere lecture) et ne pas perdre de temps a l'ecrire. Il peut eventuellement servir de doc.
Ha... Mes tests sont simple, stupides, mais de là à servir de doc.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye jouer ailleurs ;-)
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
FAb
Marc Boyer writes:
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run: [...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D Y-a-t-il des «lib» ou assimilés ?
FAb
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite
pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
[...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport
(TestResult et TestFailure) sur quel test+condition+file+line il s'est
arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la
classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D
Y-a-t-il des «lib» ou assimilés ?
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run: [...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D Y-a-t-il des «lib» ou assimilés ?
FAb
Laurent Deniau
Marc Boyer wrote:
Laurent Deniau wrote:
Marc Boyer wrote:
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des unit tests?
Non, pas vraiment. je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage) ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework" qui me posait question. Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous les tests de la classe de test (celle qui derive de TestCase), cleanup (tearDown en Java je crois) pour nettoyer tout ce que le dernier test execute a pu laisser comme ressources non liberees et testAssert pour valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL) test unitaire = methode qui teste une fonctionalite,e.g. testStringCat() TestCase = groupe de test unitaire, e.g. TestString : TestCase TestSuite = suite de groupe de test, e.g. TestString, TestArray dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux macro (le testAssert) et en appellant le reste à la main depuis un main.
CUnit existe deja. Il y a d'ailleurs plusieurs versions. Aucun ne me plait mais tu peux t'en inspirer.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye jouer ailleurs ;-)
yep. sauf que le coss-post-reative m'a fait perdre des posts...
a+, ld.
Marc Boyer wrote:
Laurent Deniau wrote:
Marc Boyer wrote:
Donc ça, ça sert à lancer tous les tests de la classe de test.
Mais les tests de la classe de tests, tu les écris à la main
individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des
unit tests?
Non, pas vraiment.
je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage)
ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de
suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework"
qui me posait question.
Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB
sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous
les tests de la classe de test (celle qui derive de TestCase), cleanup
(tearDown en Java je crois) pour nettoyer tout ce que le dernier test
execute a pu laisser comme ressources non liberees et testAssert pour
valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL)
test unitaire = methode qui teste une fonctionalite,e.g. testStringCat()
TestCase = groupe de test unitaire, e.g. TestString : TestCase
TestSuite = suite de groupe de test, e.g. TestString, TestArray
dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque
modification "significative" du code pour valider que tout continue a
fonctionner correctement selon le protocol de test. C'est pour eviter
une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux
macro (le testAssert) et en appellant le reste à la main depuis un main.
CUnit existe deja. Il y a d'ailleurs plusieurs versions. Aucun ne me
plait mais tu peux t'en inspirer.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne
parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye
jouer ailleurs ;-)
yep. sauf que le coss-post-reative m'a fait perdre des posts...
Donc ça, ça sert à lancer tous les tests de la classe de test. Mais les tests de la classe de tests, tu les écris à la main individuellement ?
On doit toujours ecrire les tests a la main. Tu n'es pas un familier des unit tests?
Non, pas vraiment. je fais les miens tout seul à la main, mais c'est tout.
Les XTest (remplace X par une lettre designant le langage) ne propose qu'un "framework" pour te faciliter l'ecriture de tests et de suite de tests. Comment veux-tu qu'il sache ce que tu veux tester?
Je me suis malk exprimé. En fait, c'était l'existence du "framework" qui me posait question. Mais en lisant ta réponse, je suis allé lire quelques pages sur le WEB sur le sujet, et je comprends mieux.
Tu as setup pour definir un standard de configuration d'entree dans tous les tests de la classe de test (celle qui derive de TestCase), cleanup (tearDown en Java je crois) pour nettoyer tout ce que le dernier test execute a pu laisser comme ressources non liberees et testAssert pour valider une condition dans ton test.
OK
Donc:
testAssert = test une condition dans un test,e.g. testAssert(s != NULL) test unitaire = methode qui teste une fonctionalite,e.g. testStringCat() TestCase = groupe de test unitaire, e.g. TestString : TestCase TestSuite = suite de groupe de test, e.g. TestString, TestArray dans OOC, derive de TestCase et peut contenir d'autre TestSuite.
OK
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe
Oui, ça j'ai commencé à faire, mais en C "tout nu" avec une ou deux macro (le testAssert) et en appellant le reste à la main depuis un main.
CUnit existe deja. Il y a d'ailleurs plusieurs versions. Aucun ne me plait mais tu peux t'en inspirer.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
OK, laissons comme ça jusqu'à ce que quelqu'un rale et nous envoye jouer ailleurs ;-)
yep. sauf que le coss-post-reative m'a fait perdre des posts...
a+, ld.
Laurent Deniau
FAb wrote:
Marc Boyer writes:
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
[...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D
Il m'a semble dire que c'etait en C, ISO C90 plus precisement.
Y-a-t-il des «lib» ou assimilés ?
CUnit. J'aime pas.
a+, ld.
FAb wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Laurent Deniau wrote:
Je derive de TestCase pour les classes de test et j'utilise TestSuite
pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
[...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport
(TestResult et TestFailure) sur quel test+condition+file+line il s'est
arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la
classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D
Il m'a semble dire que c'etait en C, ISO C90 plus precisement.
Je derive de TestCase pour les classes de test et j'utilise TestSuite pour les grouper en suites de tests.
TestCase fourni deux methodes de run:
[...]
L'interet c'est que TestCase bloque les exceptions et fait un rapport (TestResult et TestFailure) sur quel test+condition+file+line il s'est arrete. Dans le cas d'une TestSuite, un test stoppe les tests de la classe en cours mais ne stoppe pas toute la suite.
Même question en C :-D
Il m'a semble dire que c'etait en C, ISO C90 plus precisement.
Je pense que les auteurs n'ont pas fait de leur mieux pour que ce soit reutilise par d'autres. Et c'est franchement basique. Il aurait pu faire la meme chose que JUnit en remplacant simplement la reflection par l'enregistrement des fonctions de test. Mettre un setup et un cleanup sur un ADT user-define qu'il passerait ensuite au fonctions de test me parait un minimum. Grouper les tests en Suite et pouvoir les appeller par leur nom ou nom de groupe permet de faire des tests cibles. Bref je doute que les auteurs aient utilise ca de facon intensive. Je peux me tromper mais ils sont volontaires alors ;-)
a+, ld.
cedric wrote:
Laurent Deniau wrote:
CUnit. J'aime pas.
Pour quelles raisons ?
Pas bo et c'est C99 (commentaires)
Je pense que les auteurs n'ont pas fait de leur mieux pour que ce soit
reutilise par d'autres. Et c'est franchement basique. Il aurait pu faire
la meme chose que JUnit en remplacant simplement la reflection par
l'enregistrement des fonctions de test. Mettre un setup et un cleanup
sur un ADT user-define qu'il passerait ensuite au fonctions de test me
parait un minimum. Grouper les tests en Suite et pouvoir les appeller
par leur nom ou nom de groupe permet de faire des tests cibles. Bref je
doute que les auteurs aient utilise ca de facon intensive. Je peux me
tromper mais ils sont volontaires alors ;-)
Je pense que les auteurs n'ont pas fait de leur mieux pour que ce soit reutilise par d'autres. Et c'est franchement basique. Il aurait pu faire la meme chose que JUnit en remplacant simplement la reflection par l'enregistrement des fonctions de test. Mettre un setup et un cleanup sur un ADT user-define qu'il passerait ensuite au fonctions de test me parait un minimum. Grouper les tests en Suite et pouvoir les appeller par leur nom ou nom de groupe permet de faire des tests cibles. Bref je doute que les auteurs aient utilise ca de facon intensive. Je peux me tromper mais ils sont volontaires alors ;-)
a+, ld.
bruno modulix
(snip)
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe par des tests qui ratent expres (perso je zappe souvent cette etape) pour valider le test lui-meme.
La dernière fois que j'ai omis cette étape, je m'en suis mordu les doigts...
(snip)
a+, ld.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
ps : je repositionne le fu2 sur fcldev - mon intervention n'ayant aucun rapport avec le C !-)
Bruno
(snip)
L'idee des unit tests est qu'ils doivent etre executes apres chaque
modification "significative" du code pour valider que tout continue a
fonctionner correctement selon le protocol de test. C'est pour eviter
une marche arriere du projet. Le depart des tests commence en principe
par des tests qui ratent expres (perso je zappe souvent cette etape)
pour valider le test lui-meme.
La dernière fois que j'ai omis cette étape, je m'en suis mordu les doigts...
(snip)
a+, ld.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne
parle que de ce que j'ai fait en C.
ps : je repositionne le fu2 sur fcldev - mon intervention n'ayant aucun
rapport avec le C !-)
L'idee des unit tests est qu'ils doivent etre executes apres chaque modification "significative" du code pour valider que tout continue a fonctionner correctement selon le protocol de test. C'est pour eviter une marche arriere du projet. Le depart des tests commence en principe par des tests qui ratent expres (perso je zappe souvent cette etape) pour valider le test lui-meme.
La dernière fois que j'ai omis cette étape, je m'en suis mordu les doigts...
(snip)
a+, ld.
PS. je laisse le fu sur fclc parce que je ne lis pas fcd et que je ne parle que de ce que j'ai fait en C.
ps : je repositionne le fu2 sur fcldev - mon intervention n'ayant aucun rapport avec le C !-)
