Si tu utilises assert(), ce n'est pas des tests unitaires.
Si la condition est fausse, tu va planter.
Tu ne vas donc pas pouvoir enchaîner les tests et tu ne sauras pas directement combien d'erreurs tu as.
De plus, les assertions ne sont qu'une partie des tests unitaires, il y a tout ce qui est fixture, déclaration du test, informations relatives aux tests …
Sans compter que tu ne pourras pas exploiter facilement les résultats.
Si tu utilises les assert dans la méthode à tester :
- pour tester les pré-condition
Je pense qu'on touche un autre type de tests (tests d'intégration ?).
Mais il faut aussi que ton code marche en release et donc qu'on puisse entrer des valeurs invalides sans qu'il y ai d'asserts activés.
À moins bien sûr que tu n'indique que l'insertion de valeurs erronées doit entraîner un comportement indéterminé en release.
Mais ce serait bien de pouvoir tester la présence de l'assert en debug. Mais là on touche la gestion des signaux…
Acquitter un SIGABR devrait être facile, mais ce serait bien, quitte à faire, d'aussi d'acquitter d'autres signaux comme des SEGFAULT…
- pour les post-conditions
Si tu as des classes filles qui héritent d'une classe mère, elles ont normalement des mêmes post-conditions communes.
Soit tu duplique ton code, soit tu utilises une méthode commune.
On ne peut pas dire que ce soit vraiment génial. De plus des problèmes évoqués plus haut, on ne peut pas faire du TDD de cette manière.
Le TDD c'est "on écrit un test, ça plante, on corrige en mode gros fainéant, ça ne plante plus, on cherche un nouveau test pour faire planter puis on itère".
Le test des résultats doit donc être externalisé.
Après, tester les post-conditions avec des asserts… c'est génial pour détecter des erreurs (tests intégration ?) mais :
- il faut les écrire, je suis sûr qu'au bout d'un moment on a sa claque d'écrire toujours les mêmes choses ;
- il faut éviter les redondances avec le code :
.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 int add(int a, int b) { int result = a + b; assert( result == a + b); return result; }
Donc au final, je pense qu'il vaut mieux les utiliser pour vérifier les plages de valeurs en sorties, tout comme pour les pré-conditions avec les plages de valeurs en entrée.
Le comportement, le résultat en lui-même sera plus du ressort des tests unitaires.
Encore un autre problème, si tu testes ton code avec gdb, tu connais la ligne, le fichier, la valeur des variables, c'est génial.
Mais personnellement, je ne lance que très rarement gdb quand je compile et que j'exécute.
Si ça plante, je relance avec gdb.
Mais quid du fait que tu distribues une version "debug" compilée à tes amis et qu'il y ai un bug qui se produit une fois tout les 32 du mois ?
Comment fais-tu pour le reproduire ? Tu sais juste que ça a planté puis voilà.
Mais là, on est plus du tout dans une problématique de tests unitaires.
Pour cela, j'ai une autre astuce pour récupérer le signal et la pile d'appel (donc aussi fichier + ligne), même en release et ce gratuitement.
Mais si tout a bien été testé unitairement, l'erreur ne devrait pas trop être éloignée.
Ce serait bien d'y ajouter plus d'informations, comme la valeur de quelques variables utilisées, mais cela aurait un coût et il faut bien s'arrêter quelque part.
En tout cas merci bien… à cause de toi, ça sent une version 0.0.2 avec gestion des signaux dans les tests unitaires
Partager