La couverture de code à 100% est-elle un rêve de pipe?

Est-il possible de s'attendre à une couverture de code à 100% dans les applications Web lourdes jquery / backbonejs? Est-il raisonnable d'échouer un sprint car la couverture à 100% n'est pas respectée lorsque la couverture de code réelle oscille entre 92% et 95% en javascript / jquery?

C'est tout aussi réaliste que irréaliste.

Réaliste
Si vous avez des tests automatisés qui se sont avérés couvrir toute la base de code, alors insister sur une couverture à 100% est raisonnable.
Cela dépend également de l'importance du projet. Plus il est critique, plus il est raisonnable d'attendre / exiger une couverture complète du code.
Il est plus facile de le faire pour des projets de petite à moyenne taille.

Irréaliste
Vous commencez à 0% de couverture ...
Le projet est monstrueux avec de très nombreux chemins d'erreur difficiles à recréer ou à déclencher.
La direction n'est pas disposée à s'engager / investir pour s'assurer que la couverture est là.

J'ai travaillé sur toute la gamme de projets, allant de l'absence de couverture à un niveau décent. Jamais un projet à 100%, mais il y a certainement eu des moments où j'aurais souhaité avoir une couverture plus proche de 100%.
En fin de compte, la question est de savoir si la couverture existante satisfait suffisamment des cas requis pour que l'équipe soit à l'aise pour expédier le produit.

Nous ne connaissons pas l'impact d'un échec sur votre projet, nous ne pouvons donc pas dire si 92% ou 95% est suffisant, ou si ce 100% est vraiment requis. Ou d'ailleurs, le 100% teste entièrement tout ce que vous attendez.

Qui teste les tests?

Il est au mieux très naïf et irréaliste même au sens théorique et peu pratique au sens commercial.

• C'est irréaliste avec un code qui a une grande complexité cyclomatique. Il y a trop de variables pour couvrir chaque combinaison.
• Il est irréaliste avec du code fortement concurrent. Le code n'est pas déterministe, vous ne pouvez donc pas couvrir toutes les conditions susceptibles de se produire car le comportement changera à chaque exécution de test.
• C'est irréaliste dans un sens commercial, cela ne rapporte vraiment que d'écrire des tests pour du code qui est du code de chemin critique, c'est-à-dire du code qui est important et du code qui peut changer fréquemment.

Tester chaque ligne de code n'est pas un bon objectif

Il est très coûteux d'écrire des tests, c'est du code qui doit être écrit et testé lui-même, c'est du code qui doit être documenté dans ce qu'il essaie réellement de tester, c'est du code qui doit être maintenu avec des changements de logique métier et les tests échouent car ils sont obsolètes. La maintenance des tests automatisés et de la documentation les concernant peut être plus coûteuse que la maintenance du code parfois.

Cela ne veut pas dire que les tests unitaires et les tests d'intégration ne sont pas utiles, mais seulement là où ils ont un sens, et en dehors des industries qui peuvent tuer des gens, il n'est pas logique d'essayer de tester chaque ligne de code dans une base de code. En dehors de ces tueries critiques, de nombreuses personnes codent rapidement les bases, il est impossible de calculer un retour sur investissement positif qu'une couverture de code à 100% impliquerait.

Arrêt du problème:

Dans la théorie de la calculabilité, le problème d'arrêt est le problème de déterminer, à partir d'une description d'un programme informatique arbitraire et d'une entrée, si le programme se terminera ou continuera de fonctionner indéfiniment.

Alan Turing a prouvé en 1936 qu'un algorithme général pour résoudre le problème d'arrêt pour toutes les paires d'entrée de programme possibles ne pouvait pas exister. Un élément clé de la preuve était une définition mathématique d'un ordinateur et d'un programme, qui est devenu connu comme une machine de Turing; le problème d'arrêt est indécidable sur les machines Turing. C'est l'un des premiers exemples d'un problème de décision.

Puisque vous ne pouvez même pas prouver que quelque chose fonctionne à 100%, pourquoi en faire votre objectif?

Clair et simple, dans la plupart des cas, cela n'a aucun sens commercial.

Dans la plupart des cas, une couverture de code à 100% signifie que vous avez un peu "triché":

• Des parties complexes et changeantes du système (comme l'interface graphique) ont été déplacées vers des modèles déclaratifs ou d'autres DSL.
• Tout le code touchant les systèmes externes a été isolé ou géré par des bibliothèques.
• Il en va de même pour toute autre dépendance, en particulier celles nécessitant des effets secondaires.

Fondamentalement, les pièces difficiles à tester ont été déplacées vers des zones où elles ne sont pas nécessairement considérées comme du "code". Ce n'est pas toujours réaliste, mais notez que indépendamment de vous aider à tester, toutes ces pratiques facilitent le travail sur votre base de code.

Pour un exemple impressionnant et réel de couverture de 100% des succursales , consultez Comment SQLite est testé .

Je me rends compte que votre question concerne spécifiquement le javascript, qui est un type de produit logiciel complètement différent, mais je veux faire prendre conscience de ce qui peut être fait avec une motivation suffisante.

Une couverture de code à 100% pour les tests unitaires pour toutes les pièces d'une application particulière est un rêve de pipe, même avec de nouveaux projets. Je souhaite que ce soit le cas, mais parfois vous ne pouvez tout simplement pas couvrir un morceau de code, peu importe à quel point vous essayez d'abstraire les dépendances externes. Par exemple, supposons que votre code doive appeler un service Web. Vous pouvez masquer les appels de service Web derrière une interface afin de pouvoir vous moquer de cet élément et tester la logique métier avant et après le service Web. Mais l'élément réel qui doit invoquer le service Web ne peut pas être testé à l'unité (très bien de toute façon). Un autre exemple est si vous devez vous connecter à un serveur TCP. Vous pouvez masquer le code qui se connecte à un serveur TCP derrière une interface. Mais le code qui se connecte physiquement à un serveur TCP ne peut pas être testé à l'unité, car s'il est arrêté pour une raison quelconque, cela entraînerait l'échec du test unitaire. Et les tests unitaires doivent toujours réussir, quel que soit le moment où ils sont invoqués.

Une bonne règle de base est que toute votre logique métier doit avoir une couverture de code à 100%. Mais les pièces qui doivent invoquer des composants externes, il devrait avoir une couverture de code aussi proche que 100% que possible. Si vous ne pouvez pas l'atteindre, je ne le ferais pas trop transpirer.

Beaucoup plus important, les tests sont-ils corrects? Reflètent-ils fidèlement votre entreprise et les exigences? Avoir une couverture de code juste pour avoir une couverture de code ne signifie rien si tout ce que vous faites est de tester incorrectement ou de tester un code incorrect. Cela étant dit, si vos tests sont bons, une couverture de 92 à 95% est exceptionnelle.

Je dirais que si le code n'est pas conçu dans le but spécifique de permettre une couverture de test à 100%, 100% peut ne pas être réalisable. L'une des raisons serait que si vous codez de manière défensive - ce que vous devriez - vous devriez parfois avoir du code qui gère des situations qui, selon vous, ne devraient pas se produire ou ne peuvent pas se produire compte tenu de votre connaissance du système. Couvrir un tel code avec des tests serait par définition très difficile. Ne pas avoir un tel code peut être dangereux - et si vous vous trompez et que cette situation se produit une fois sur 256? Que se passe-t-il s'il y a un changement de lieu indépendant qui rend une chose impossible possible? Etc. Donc, 100% peut être assez difficile à atteindre par des moyens "naturels" - par exemple, si vous avez du code qui alloue de la mémoire et que vous avez du code qui vérifie s'il a échoué, à moins que vous ne vous moquiez du gestionnaire de mémoire (ce qui peut ne pas être facile) et écrivez un test qui renvoie "out of memory", couvrant ce code peut être difficile. Pour l'application JS, il peut s'agir d'un codage défensif autour des bizarreries DOM possibles dans différents navigateurs, d'éventuelles défaillances de services externes, etc.

Je dirais donc que l'on devrait s'efforcer d'être aussi proche de 100% que possible et avoir une bonne raison pour le delta, mais je ne verrais pas ne pas obtenir exactement 100% comme nécessairement un échec. 95% peut convenir à un gros projet, selon ce que sont les 5%.

Si vous commencez avec un nouveau projet et que vous utilisez strictement une méthodologie de test d'abord, il est tout à fait raisonnable d'avoir une couverture de code à 100% dans le sens où tout votre code sera invoqué à un moment donné lorsque vos tests auront été exécuté. Cependant, vous ne pouvez pas avoir explicitement testé chaque méthode ou algorithme individuel directement en raison de la visibilité de la méthode, et dans certains cas, vous pouvez ne pas avoir testé certaines méthodes, même indirectement.

Faire tester 100% de votre code est potentiellement un exercice coûteux, en particulier si vous n'avez pas conçu votre système pour vous permettre d'atteindre cet objectif, et si vous concentrez vos efforts de conception sur la testabilité, vous ne donnez probablement pas assez d'attention à la conception de votre application pour répondre à ses exigences spécifiques, en particulier lorsque le projet est important. Je suis désolé, mais vous ne pouvez tout simplement pas avoir les deux choses sans que quelque chose soit compromis.

Si vous introduisez des tests dans un projet existant où les tests n'ont pas été maintenus ou inclus auparavant, il est impossible d'obtenir une couverture de code à 100% sans que les coûts de l'exercice l'emportent sur l'effort. Le mieux que vous puissiez espérer est de fournir une couverture de test pour les sections critiques du code les plus appelées.

Est-il raisonnable d'échouer un sprint car la couverture à 100% n'est pas respectée lorsque la couverture de code réelle oscille entre 92% et 95% en javascript / jquery?

Dans la plupart des cas, je dirais que vous ne devriez considérer que votre sprint a «échoué» que si vous n'avez pas atteint vos objectifs. En fait, je préfère ne pas penser que les sprints échouent dans de tels cas parce que vous devez pouvoir apprendre des sprints qui ne répondent pas aux attentes afin de bien planifier votre prochaine fois que vous définissez un sprint. Quoi qu'il en soit, je ne pense pas qu'il soit raisonnable de considérer la couverture du code comme un facteur de succès relatif d'un sprint. Votre objectif devrait être d'en faire juste assez pour que tout fonctionne comme spécifié, et si vous codez d'abord le test, vous devriez être en mesure de vous assurer que vos tests soutiendront cet objectif. Tout test supplémentaire que vous pensez avoir besoin d'ajouter est effectivement un enrobage de sucre et donc une dépense supplémentaire qui peut vous empêcher de terminer vos sprints de manière satisfaisante.

Je ne le fais pas naturellement, mais je l'ai fait sur deux grands projets. Si vous avez quand même un cadre pour les tests unitaires, ce n'est pas difficile exactement, mais cela ajoute beaucoup de tests.

Y a-t-il un obstacle particulier que vous rencontrez qui vous empêche de frapper ces dernières lignes? Si ce n'est pas le cas, si obtenir une couverture de 95% à 100% est simple, vous pouvez aussi bien le faire. Puisque vous êtes ici demander, je vais supposer qu'il y a quelque chose. Qu'est-ce que c'est?

92%, c'est bien. Je pense que les vraies questions sont:

• 92% est-elle la «nouvelle» norme maintenant? Si le prochain sprint a 88% de tests, ça va aller? C'est souvent le début de l'abandon des suites de tests.

• À quel point est-il important que le logiciel fonctionne sans bogues? Vous avez des tests pour ces raisons, pas "pour le plaisir de tester"

• Y a-t-il un plan pour revenir en arrière et remplir les tests manquants?

• Pourquoi testez-vous? Il semble que l'accent soit mis sur le% de la ligne couverte et non sur la fonctionnalité

Martin Fowler écrit dans son blog :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Cependant, il existe même des normes qui imposent une couverture à 100% au niveau de l'unité. Par exemple, c'est l'une des exigences des normes de la communauté européenne des vols spatiaux (ECSS, Coopération européenne pour la normalisation spatiale). L'article lié ici , raconte une histoire intéressante de projet qui avait pour objectif d'atteindre une couverture de test de 100% dans un logiciel déjà terminé. Il est basé sur des entretiens avec les ingénieurs impliqués qui ont développé les tests unitaires.

Certaines des leçons sont les suivantes:

• Une couverture à 100% est inhabituelle mais réalisable
• Une couverture à 100% est parfois nécessaire
• Une couverture à 100% apporte de nouveaux risques
• Ne pas optimiser pour le 100% métrique
• Développer une stratégie appropriée pour maximiser la couverture
• Une couverture à 100% n'est pas une condition suffisante pour une bonne qualité

Peut-être que demander si c'est faisable et raisonnable ne sont pas les questions les plus utiles à poser. La réponse la plus pratique est probablement celle qui est acceptée. J'analyserai cela à un niveau plus philosophique.

Une couverture à 100% serait idéale, mais idéalement, elle ne serait pas nécessaire ou serait beaucoup plus facile à réaliser. Je préfère penser si c'est naturel et humain que faisable ou raisonnable.

L'acte de programmer correctement est presque impossible avec les outils d'aujourd'hui. Il est très difficile d'écrire du code totalement correct et sans bogues. Ce n'est tout simplement pas naturel. Donc, sans autre option évidente, nous nous tournons vers des techniques telles que TDD et le suivi de la couverture du code. Mais tant que le résultat final est toujours un processus contre nature, vous aurez du mal à amener les gens à le faire de manière cohérente et heureuse.

Atteindre une couverture de code à 100% n'est pas un acte naturel. Pour la plupart des gens, les forcer à y parvenir serait une forme de torture.

Nous avons besoin de processus, d'outils, de langages et de code qui correspondent à nos modèles mentaux naturels. Si nous ne le faisons pas, il n'y a aucun moyen de tester la qualité d'un produit.

Il suffit de regarder tous les logiciels disponibles aujourd'hui. La plupart de ça gâche assez régulièrement. Nous ne voulons pas croire cela. Nous voulons croire que notre technologie est magique et nous rendre heureux. Et nous choisissons donc d'ignorer, d'excuser et d'oublier la plupart du temps que notre technologie est en panne. Mais si nous prenons une évaluation honnête des choses, la plupart des logiciels disponibles aujourd'hui sont assez merdiques.

Voici quelques efforts pour rendre le codage plus naturel:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

Ce dernier est extrêmement incomplet et expérimental. En fait, c'est un projet que j'ai commencé, mais je crois que ce serait un énorme pas en avant pour le métier de la programmation si je pouvais un jour m'y consacrer pour le terminer. Fondamentalement, c'est l'idée que si les contrats expriment les seuls aspects d'un comportement de classe qui nous intéressent, et que nous exprimons déjà les contrats sous forme de code, pourquoi ne pas seulement avoir les définitions de classe et de méthode avec les contrats. De cette façon, les contrats seraient le code, et nous n'aurions pas besoin de mettre en œuvre toutes les méthodes. Laissez la bibliothèque découvrir comment honorer les contrats pour nous.

Atteindre 100% sur le nouveau code devrait être très réalisable et si vous pratiquez le TDD, vous l'atteindrez probablement par défaut car vous écrivez très délibérément des tests pour chaque ligne de code de production.

Sur le code hérité existant qui a été écrit sans tests unitaires, cela peut être difficile car souvent le code hérité n'a pas été écrit avec des tests unitaires à l'esprit et peut nécessiter beaucoup de refactoring. Ce niveau de refactoring n'est souvent pas pratique compte tenu des réalités du risque et du calendrier, vous devez donc faire des compromis.

Dans mon équipe, je spécifie une couverture de code à 100% et si nous voyons moins que cela dans la revue de code, le propriétaire technique du composant explique pourquoi le 100% n'a pas été atteint avec le développeur et doit être d'accord avec le raisonnement du développeur. Souvent, s'il y a un problème à 100%, le développeur en parlera au propriétaire technique avant la révision du code. Nous avons constaté qu'une fois que vous preniez l'habitude et appreniez des techniques pour contourner plusieurs problèmes courants avec l'ajout de tests au code hérité, il n'est pas aussi difficile de penser à 100% régulièrement.

Le livre de Michael Feather " Travailler efficacement avec le code hérité " nous a été très précieux pour trouver des stratégies pour ajouter des tests à notre code hérité.

Non, ce n'est pas possible et ça ne le sera jamais. S'il était possible, toutes les mathématiques tomberaient dans le finitisme. Par exemple, comment testeriez-vous une fonction qui a pris deux entiers 64 bits et les a multipliés? Cela a toujours été mon problème avec les tests par rapport à la vérification d'un programme correct. Pour tout sauf les programmes les plus triviaux, les tests sont essentiellement inutiles car ils ne couvrent qu'un petit nombre de cas. C'est comme vérifier 1000 nombres et dire que vous avez prouvé la conjecture de Goldbach.