100% de couverture de code dans les tests automatisés

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.

Mon expérience avec les tests automatisés

Je me souviens 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» que sont les tests automatisés 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? 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 dans mes tests automatisés?

Évidemment, vous pouvez simplement lancer un nombre et vous commettre à celui-ci. Nous pourrions viser la perfection avec 100% de couverture de code, autant que nous pourrions être raisonnables et viser 80% de couverture de code. 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 aveuglément 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 cent testeurs pour vérifier votre système? Mettriez-vous votre carrière en jeu?

Tester pour s'améliorer ou pour atteindre des cibles?

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 concernera l’augmentation de votre niveau de confiance. N’hésitez pas à partager vos pensées avec moi!