Blogue

100% de couverture de code ?

Les tests automatisés sont en quelque sorte un « gardien invisible » qui est non seulement génial, mais qui augmentera aussi votre confiance en tant que développeur. Lorsqu’ils sont bien écrits, ils vous donnent la liberté de faire des changements dans votre code sans aucune crainte. Vous pouvez ajouter des fonctionnalités sans rien briser.

Je me rappelle de ce projet où nous avons fait des changements majeurs à notre architecture dans le « backend ». Sans les changer, nos tests de haut niveau nous ont guidés pendant le réusinage. Nous n’avons absolument rien brisé. Aucun bogue ne s’est ajouté dans la liste cette semaine-là. C’est un sentiment indescriptible. Il est difficile de faire comprendre à un gestionnaire de projet comment ce « gardien invisible » améliore réellement votre confiance et vous permet d’économiser beaucoup de temps.

J’ai discuté avec plusieurs développeurs et un sujet sortait toujours du lot : les tests. Comment devrais-je les approcher, comment puis-je améliorer ma stratégie de test, et ainsi de suite. Bien que ces questions restent fort intéressantes, je dois admettre qu’il y en a une qui a vraiment attiré mon attention récemment :

Quelle est la couverture de code idéale que je devrais viser?

Évidemment, vous pouvez simplement lancer un nombre et vous commettre à celui-ci. Nous pourrions viser la perfection et lancer 100%, autant que nous pourrions être raisonnables et viser 80%. En fait, aucune de ces réponses ne me convient. Même si, alors que c’est presque impossible, mon logiciel a une couverture de code de 100%, je peux toujours faire des changements aveuglement et briser des fonctionnalités. Comment est-ce possible si tout mon logiciel est, théoriquement, testé?

Répondre à la question avec un nombre veut dire que nous ne comprenons tout simplement pas l’objectif des tests automatisés. Pourquoi voudriez-vous viser aveuglément une métrique? En fait, la vraie question n’est pas exactement à propos des métriques. C’est à propos de la confiance. Vous ne devriez pas viser un pourcentage, mais plutôt un niveau de confiance. À quel point êtes-vous confiant à propos de votre système actuel ? Que se passerait-il si j’engageais demain une équipe de 100 testeurs pour vérifier votre système ? Mettriez-vous votre carrière en jeu ?

La dernière affirmation est un peu extrême et j’ose imaginer qu’elle ne se produira jamais. Nous, les humains, faisons des erreurs. Ça arrive. Mais vous pouvez définitivement changer votre attitude. Vous devez vous efforcer de valider le comportement de vos fonctionnalités, et non le détail de vos méthodes. Tester l’état interne d’une classe ne vous donne pas ce haut niveau de confiance dont vous avez besoin pour itérer rapidement. En fait, viser un pourcentage vous mènera à créer de « faux tests » simplement dans l’objectif de l’atteindre. Vous aurez ainsi un faux sentiment de confiance et ceci vous mènera vraisemblablement à un « legacy system ».

Les belles applications vont certainement attirer les consommateurs, mais les bogues vont les repousser. Un beau « look and feel » ne compensera pas un système qui ne fonctionne pas. Par conséquent, un haut niveau de confiance sera certainement un atout pour conserver votre audience.

J’imagine que votre prochaine préoccupation devrait concerner l’augmentation de votre niveau de confiance. N’hésitez pas à partager vos pensées avec moi.

Partagez cette publication

Commentaire (0)

Laisser un commentaire