Salut,
Suite à la dépêche (relativement controversée) de Lucas Nussbaum sur les modes de développement logiciels, j'ai eu envie de m'essayer aux tests unitaires. J'ai donc installé et mis en place une infrastructure CppUnit pour gérer les tests.
Mais bien sur, comme je débute en tests unitaires, je bute sur une question bien bête: pour mon application, je code quelques classes qui serviront à gérer les logs du programme (en gros, une encapsulation/interface à log4cpp). Bien sur, comme je veux être bon élève, je veux écrire les tests avant le code… Mais comment tester unitairement un système de logs?
Ma première idée était de simplement démarrer le système de logs, logger deux trois trucs, puis ouvrir le fichier de log et valider son contenu, mais est-ce que cela se qualifie comme test unitaire ? J'ai l'impression de tester le fonctionnement du composant à un trop haut niveau. Est-ce que je me trompe (ie. c'est très bien ce que je fais), ou dans le cas contraire, quels tests devrais-je faire?
Merci à ceux qui ont des idées sur la question!
# boaf
Posté par kesako . Évalué à 2.
surtout les tests automatisés
c'est tres souvent du beurre barbouillé sur les lunettes des "decideurs" qui veulent pouvoir dire qu'il y a des tests. Mais ne veulent pas alouer le budget pour faire une vraie qualification...
C'est parfois des tests tellement triviaux tellement inutiles...
Dans ton exemple ce qui compte c'est ce qui est effectivement ecrit dans les log , pas les carracteres et les chiffres mais le sens de ce qui est ecrit . Et ca, on ne peut generalement pas automatiser. De plus a la moindre modif du format , faut revoir les tests.
Donc tous les programmeurs en arrivent a la meme conclusion : ton exemple est un test unitaire. inutile d'en faire plus. ne te fatigue pas.
Le vrai test fonctionnel ce sera dans le cahier de recette : je fais telle manip , cela va faire ceci ou cela et logger ceci ou cela . Est ce que les logs sont bien là et sont corrects ?
ce genre de verif ne peut se faire que par un humain.
[^] # Re: boaf
Posté par Sisyphe Plâtrier . Évalué à 1.
# Un test unitaire n'est pas forcément un programme.
Posté par mmMMOoooOMMmm . Évalué à 1.
Je pense qu'il n'est pas toujours nécessaire de sortir la grosse artillerie (faire un programme). On le fait en général quand on sait qu'on aura besoin plus tard de revalider la "fonction" au cas où on aurait modifié son corps mais pas son contrat. On le fait aussi pour des frameworks afin de standardiser une production de composants.
Et puis, un test unitaire n'est valable que pour un contrat donné. Je ne dis pas qu'il faut n'en faire qu'à la fin puisque c'est antinomique au but recherché, mais plutôt de ne pas trop dépenser d'énergie au début quand le code bouge beaucoup. Et souvent, une simple procédure en deux lignes écrite quelque part suffit.
Personnellement, je fais beaucoup de tests unitaires mais qui ne sont pas instrumentalisés. Mon code n'est évidemment pas exempt de bug, mais je pense obtenir un bon rapport code correcte / temps dépensé.
Le domaine du test unitaire est tellement vaste (me semble-t-il) que les outils existants (c'est à dire permettant de ne passer qu'un minimum de temps à mettre en place le test unitaire) ne s'applique qu'à une certaine classe de programme.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.