Non la complexité cyclomatique simplifie trop le problème.
Oui, elle a surtout l'intérêt d'être mesurable :)
Elle compte juste le nombre de branche dans une fonction, or le contenu de chaque test peut être indépendant.
Indépendant, je ne suis pas d'accord. Elle te permet d'évaluer la quantité de tests pour avoir la couverture de chemin, il reste la couverture des ensembles de données d'entrée pour chaque paramètre.
Elle ne permet pas non plus de calculer les dépendances entre fonction (couverture d'instance). Typiquement une fonction qui en appel une autre. C'est le nombre total de chemin de l'executable qui compte pas vraiment, la somme des chemins de l'ensemble de chaque fonction sans tenir compte des appels.
Il y a un mot en trop ?
Si tu dis que l'important c'est le nombre de chemin de l'exécutable alors, c'est que tu parle de tests d'intégration ou fonctionnel et ton nombre de chemin explose naturellement avec l'ajout de fonctionnalité, mais pour un même nombre de chemins (ou une augmentation pas significativement grande) tu a des designs qui sont meilleurs que d'autres.
Ensuite, c'est surtout les "états" différents qui importent, plus encore que les chemins pour y arriver (même si c'est lié). Dans une machine d'état, c'est le nombre d'état qui compte, plus que la complexité des conditions de transition.
Si on parle de tests unitaire, tu les fais en boite blanche et tu peux considérer chaque champ de ton objet comme des paramètres de ta méthode.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: chi va piano va sano
Posté par barmic . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Oui, elle a surtout l'intérêt d'être mesurable :)
Indépendant, je ne suis pas d'accord. Elle te permet d'évaluer la quantité de tests pour avoir la couverture de chemin, il reste la couverture des ensembles de données d'entrée pour chaque paramètre.
Il y a un mot en trop ?
Si tu dis que l'important c'est le nombre de chemin de l'exécutable alors, c'est que tu parle de tests d'intégration ou fonctionnel et ton nombre de chemin explose naturellement avec l'ajout de fonctionnalité, mais pour un même nombre de chemins (ou une augmentation pas significativement grande) tu a des designs qui sont meilleurs que d'autres.
Si on parle de tests unitaire, tu les fais en boite blanche et tu peux considérer chaque champ de ton objet comme des paramètres de ta méthode.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)