> Essayer de couvrir tout le code d'une classe pour chaque état de l'objet reviendrait à explorer un arbre de possibilité infinie
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...
[^] # Re: Pas si simple...
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 2.
Je ne suis pas d'accord. Le principe de la programmation objet est bien d'isoler les composants de facon a pouvoir les faire evoluer de facon autonome. Le corollaire, c'est que tu peux aussi les tester de facon autonome et donc de facon relativement finie.
S'il y a des conditions difficile a reproduire, c'est peut-etre aussi celle-la qui peuvent s'averer dangereuses. Par exemple, j'ai un protocole de communication sans-contact. C'est dur de simuler la perte de paquet dans le protocole, mais c'est hyper important de le faire, quitte a modifier un peu l'architecture de la gestion du protocole.
> Je trouve ça plus logique qu'on code une fonction à partir des spécifs
Dans le monde ideal, c'est comme ca. Dans le monde reel, il faut s'adapter. Moi je preconise deux approches:
- une approche black-box ou le testeur se base sur les specifs et test ce qui lui parait le plus important
- une approche transparent box ou le developpeur titille son programme la ou il sait que ca peut faire mal. Dans l'exemple que j'ai donne plus haut, un testeur ne pensera pas forcement a tester avec a = -b mais le developpeur lui saura que c'est une valeur cle a verifier.
Le plus proche d'un outil de couverture de code et couverture de chemin d'execution, c'est le cerveau du programmeur. Faire des tests uniquement en black-box (a partir des specifs), c'est se passer de cet outil.
> Il s'agit de générer des mutants
Super idee. Je vais chercher des references et voir si je peux mettre ca en pratique. En c, ca va etre un peu lourd...