Faut-il exclure le code pour l'analyse de la couverture du code?

Je travaille sur plusieurs applications, principalement les anciennes. Actuellement, leur couverture de code est assez faible: généralement entre 10 et 50%.

Depuis plusieurs semaines, nous avons des discussions récurrentes avec les équipes de Bangalore (l'essentiel du développement se fait à l'étranger en Inde) concernant les exclusions de packages ou de classes pour Cobertura (notre outil de couverture de code, même si nous migrons actuellement vers JaCoCo).

Leur point de vue est le suivant: comme ils n'écriront aucun test unitaire sur certaines couches de l'application (1) , ces couches devraient être simplement exclues de la mesure de couverture du code. En d'autres termes, ils veulent limiter la mesure de couverture du code au code testé ou devant être testé .

De plus, lorsqu'ils travaillent sur des tests unitaires pour une classe complexe, les avantages - purement en termes de couverture de code - ne seront pas remarqués dans une grande application. Réduire la portée de la couverture du code rendra ce genre d'effort plus visible ...

L'intérêt de cette approche est que nous aurons une mesure de couverture de code qui indique l'état actuel de la partie de l'application que nous considérons comme testable .

Cependant, mon point de vue est que nous simulons en quelque sorte les chiffres. Cette solution est un moyen facile d'atteindre un niveau supérieur de couverture de code sans aucun effort. Un autre point qui me dérange est le suivant: si nous montrons une augmentation de couverture d'une semaine à l'autre, comment savoir si cette bonne nouvelle est due au bon travail des développeurs, ou simplement à de nouvelles exclusions?

De plus, nous ne pourrons pas savoir exactement ce qui est considéré dans la mesure de couverture du code. Par exemple, si j'ai 10 000 lignes d'application de code avec 40% de couverture de code, je peux déduire que 40% de ma base de code est testée (2) . Mais que se passe-t-il si nous fixons des exclusions? Si la couverture du code est désormais de 60%, que puis-je déduire exactement? Que 60% de ma base de code "importante" est testée? Comment puis-je

En ce qui me concerne, je préfère conserver la "vraie" valeur de couverture du code, même si nous ne pouvons pas nous réjouir. De plus, grâce à Sonar, nous pouvons facilement naviguer dans notre base de code et connaître, pour tout module / package / classe, sa propre couverture de code. Mais bien sûr, la couverture mondiale du code sera toujours faible.

Quelle est votre opinion à ce sujet? Comment faites-vous sur vos projets?

Merci.

(1) Ces couches sont généralement liées aux beans UI / Java, etc.

(2) Je sais que ce n'est pas vrai. En fait, cela signifie seulement que 40% de ma base de code

J'exclus généralement le code généré automatiquement, tel que les clients WCF générés par Visual Studio. Il y a généralement beaucoup de lignes de code et nous ne les testerons jamais. Cela rend très démoralisant d'augmenter les tests sur une grande partie du code ailleurs et d'augmenter la couverture de code de 0,1% seulement.

J'exclurai également les interactions entre les couches de données, tant que l'équipe peut affirmer avec certitude que cette couche est aussi mince que possible. Bien que vous puissiez affirmer que si la couche est mince, elle n'aura pas d'effet massif, elle laisse beaucoup de composants dans le rapport de couverture avec 0% contre eux, donc nous ne remarquons pas nécessairement ceux dont nous avons besoin vraiment inquiéter. La couche d'interface utilisateur pourrait être argumentée de manière similaire, selon le cadre utilisé.

Mais, en guise de contre-point, je vais également exclure les tests unitaires eux-mêmes. Ils devraient toujours avoir une couverture de ~ 100% et ils représentent un pourcentage élevé de la base de code, biaisant dangereusement les chiffres.

Bonne question. En général, j'ai tendance à exclure le code de la couverture du code pour certaines raisons, par exemple:

• généré
• héritage (n'est plus mis à jour)
• le voici: certaines couches, je n'ai pas l'intention de tester

Pourquoi le dernier point? Je pense que c'est une bonne pratique de se concentrer sur les choses qui m'intéressent, tout en supprimant les distractions. Si vous n'avez pas l'intention de tester la couche UI, pourquoi en tenir compte - cela détournerait l'attention de la partie importante de votre logiciel - la logique métier.

MAIS:

1. Vous devriez avoir une bonne raison, pourquoi exclure une certaine couche des tests unitaires (il peut y avoir des questions - de votre patron, de vos coéquipiers, de la presse ;-)
2. Si vous voulez qu'ils testent ces couches, vous devez les inclure dans les statistiques pour montrer à toute l'équipe, chaque jour, que c'est important et qu'il faut le faire.

Enfin: ne prenez pas les chiffres trop au sérieux. Une couverture de 30% peut garantir la solidité d'un logiciel, lorsqu'il en est la partie essentielle.

J'ai tendance à être d'accord avec vous et à inclure tout le code pertinent dans les mesures de couverture du code (et Sonar en général). Même si vous ne prévoyez pas de tester certaines parties du code (dans un avenir prévisible), les mesures doivent refléter l'état réel. Cela vous oblige à avoir une raison impérieuse de ne pas écrire de tests pour une partie importante de la base de code. Finalement (une fois que d'autres parties plus importantes du code sont déjà couvertes), vous pouvez reconsidérer ou choisir une manière différente d'éliminer cette dissonance - par exemple en refactorisant le code en question pour le rendre testable, ou en migrant toute la logique de celui-ci vers un une partie différente et testable de la base de code, ou même pour éliminer complètement la couche entière (si une couche ne vaut pas la peine d'être testée, a-t-elle une raison suffisante d'exister?)

Dans mes projets actuels, nous incluons également tout le code dans les métriques, à une exception près: le code généré, produisant des tas d'avertissements d'analyse statique. Comme ce code se compose généralement de classes POD énormes sans aucune logique, il n'y a rien à tester de toute façon.

Maintenant, je ne connais pas beaucoup les outils de couverture de code que vous utilisez et je ne connais pas les beans Java, mais d'après ce que vous dites, ils sont liés à l'interface utilisateur.

Avec mes connaissances limitées, j'ai ceci à dire:

1. Ne laissez aucun nombre d'outils de test gêner vos tests.
2. Si les classes sont complexes et ne peuvent pas être testées à l'unité, c'est toujours une bonne idée de les re-factoriser en classes plus compactes et testables. Cela demandera beaucoup d'efforts et de dévouement, mais cela paiera à long terme.
3. Le test des composants de l'interface utilisateur peut être difficile, mais vous pouvez toujours tester la fonction exécutée par ces composants.
4. Si vous effectuez un projet basé sur le Web, vous pouvez utiliser QUnit pour tester en bloc tout le code côté client.

Dans l'ensemble, vous devez garder à l'esprit que la couverture de code n'est qu'un chiffre et qu'une couverture de code élevée n'indique pas de bons tests. Concentrez-vous sur le fait de rendre les bibliothèques principales plus robustes et testables plutôt que de viser un pourcentage plus élevé.

Certaines exclusions ont du sens (code de plaque de chaudière qui n'a pas d'impact réel ou potentiel d'impact sur le bon fonctionnement de votre projet). Même la collecte de la couverture de code en tant que métrique est inutile car elle ne vous dit rien de toute façon. Une couverture de code à 100% n'est pas un véritable objectif, et un faible taux de couverture peut également ne pas être mauvais selon le projet, il est possible qu'une couverture de code de 20 à 30% couvre tout ce qui mérite d'être testé. la couverture du code ne vous indique que X% de votre code qui peut potentiellement être couvert est en fait par un type de test de qualité inconnue.

Je suggère de signaler un ensemble de mesures pour chaque couche de votre code. Ces mesures doivent inclure des informations de taille (par exemple, LoC, nombre de bibliothèques, nombre de classes ou de méthodes, etc.), des informations de test (par exemple, la couverture) et des informations sur les bogues (par exemple, trouver et corriger les taux).

Vos couches exclues auront une couverture de 0% et vos zones testées auront la couverture de 60% que vous avez mentionnée. Les informations sur la taille permettront aux utilisateurs de comprendre la quantité non testée ou testée. Les informations sur le bogue vous informeront si vous devez peut-être créer des tests pour les couches exclues et si vos tests existants fonctionnent.

Il est facile pour les entreprises de logiciels de se concentrer trop sur la pureté des métriques. Nous ne faisons pas de métriques, nous faisons de bons logiciels. Une mesure qui vous aide à fournir des logiciels de haute qualité en temps opportun est la mesure la plus honnête et la plus pure qui soit.