Le test unitaire n'est un programme que si tu veux reproduire la manip automatiquement (c'est presque une Lapalissade), ce qui n'est pas toujours facile pour un enchaînement de clic-clic-clic. Pour un système de log, c'est par exemple tester juste les différentes configurations (dans le sens large d'environnement logiciel) pour valider que tu as effectivement quelque chose en sortie et que c'est bien ce que tu attendais.
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.
# Un test unitaire n'est pas forcément un programme.
Posté par mmMMOoooOMMmm . En réponse au message Tests unitaires. É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.