Pour la question sur ce qui fait qu'un framework est bon, je pense à * Automatisation des résultats : ça sort en batch un rapport ou il y a OK ou KO sans intervention humaine et sans click dans tous les sens
* Possibilité de stubber : en fait les tests unitaires ne servent presque à rien si on fait du test fonction par fonction, il prennent beaucoup plus de sens quand on fait des tests au niveau d'un module fonctionnel complet (ça tend vers du test d'intégration), par contre il faut la possibilité de pouvoir remplacer les fonctions appelée par le module testée par des stubs de simulation qui peuvent être relativement complexes (machines d'état, mémorisation...) et on doit être capable de vérifier les parametres d'appel à ces fonctions (à chaque appel) et le nombre d'appel.
* Possibilité de faire de la couverture (avec aussi le cumul de couverture pour vérifier la couverture obtenue par un ensemble de tests complémentaires)
* Puissance d'expression des checks : c'est rarement de simples assert sur des boolean même si ça s'y rapporte souvent (mémorisation des valeurs précédantes pour des tests de convergence par exemple)
Pour la solution pratique, il existe une solution élégantes basée sur l'utilisation d'un langage de script (genre Python) et de générateur de bidding comme Ctypes ou SWIG. Ainsi il n'y a pas besoin de recompiler le code pour faire des tests U mais on peut le faire directement sur les libs du projet. En plus on gagne toute la souplesse et les libraries associées au langage de script. Je n'ai pas en tête de framework qui utilisent cette technique, mais par expérience c'est rapide de s'en faire un maison juste comme il nous convient...
# Utiliser un langage de script ?
Posté par gege (site web personnel) . En réponse au journal Frameworks de test unitaires: retour d'XP. Évalué à 4.
* Possibilité de stubber : en fait les tests unitaires ne servent presque à rien si on fait du test fonction par fonction, il prennent beaucoup plus de sens quand on fait des tests au niveau d'un module fonctionnel complet (ça tend vers du test d'intégration), par contre il faut la possibilité de pouvoir remplacer les fonctions appelée par le module testée par des stubs de simulation qui peuvent être relativement complexes (machines d'état, mémorisation...) et on doit être capable de vérifier les parametres d'appel à ces fonctions (à chaque appel) et le nombre d'appel.
* Possibilité de faire de la couverture (avec aussi le cumul de couverture pour vérifier la couverture obtenue par un ensemble de tests complémentaires)
* Puissance d'expression des checks : c'est rarement de simples assert sur des boolean même si ça s'y rapporte souvent (mémorisation des valeurs précédantes pour des tests de convergence par exemple)
Pour la solution pratique, il existe une solution élégantes basée sur l'utilisation d'un langage de script (genre Python) et de générateur de bidding comme Ctypes ou SWIG. Ainsi il n'y a pas besoin de recompiler le code pour faire des tests U mais on peut le faire directement sur les libs du projet. En plus on gagne toute la souplesse et les libraries associées au langage de script. Je n'ai pas en tête de framework qui utilisent cette technique, mais par expérience c'est rapide de s'en faire un maison juste comme il nous convient...