Les tests automatisés… plus lents que quoi au juste?

Un des mythes dans le monde du développement logiciel est certainement le fait que d’écrire des tests automatisés ralentit notre productivité. Est-ce vraiment le cas? Alors que l’on croit coder plus rapidement sans tests, en fin de compte ce n’est qu’une illusion. Ce qui est dommage, c’est que plusieurs entreprises ne voient pas la vraie valeur ajoutée de la qualité logicielle.

Examinons en profondeur le mythe des tests automatisés lents

J’aimerais vous poser la question : écrire des tests automatisés s’avère plus lent que quoi, exactement? Plus lent que d’écrire du code sans le tester? Un développeur se doit de tester son code au moins une fois, même si cela est réalisé manuellement.

Comment se déroulent vos tests manuels?

Vous vous faites une liste de scénarios possibles ou des cas de tests. Vous intégrez vos méthodes dans votre logiciel, vous démarrez le programme et vous constatez les résultats. Cela semble rapide à première vue, mais vous avez démarré un serveur, s’il y a lieu, attendu que le logiciel s’ouvre, puis recherché les résultats de votre test. Si vous trouvez un bogue, vous devrez refaire cette lourde procédure après la correction de celui-ci.

Et avec des tests automatisés?

Vous faites la même liste de scénarios représentant vos cas de tests. Vous traduisez vos scénarios en code une seule fois. Vous écrivez ensuite votre code et vous voyez les résultats instantanément, en quelques secondes. C'est l'avantage principal des tests automatisés.

Pourquoi avoir besoin de démarrer votre logiciel pour savoir si votre méthode fonctionne? Lorsque vous trouvez un bogue, vous n'avez qu'à changer votre code et vous voyez vos nouveaux résultats sur-le-champ. Vous n’avez pas à répéter le processus de tester étant donné qu’il a déjà été écrit! Utiliser des tests automatisés vous permet donc d'être plus agile dans votre processus.

Ce qui est vraiment intéressant au final, c’est que vos tests existeront encore dans plusieurs mois. Vous serez donc toujours certains dans le futur que vos méthodes fonctionnent, avec une preuve à l’appui (oui, tous les tests ont passé!). De plus, les tests sont une belle référence pour les développeurs afin de comprendre vos méthodes, car ils sont des exemples d’utilisation. Il est là, le retour sur investissement des tests automatisés.

Valider la régression, une valeur ajoutée

S’assurer que son logiciel fonctionne est essentiel. S’assurer qu’il fonctionne encore après l’ajout d’une fonctionnalité est tout autant primordial. Lors d’une modification, refaire les mêmes anciens tests est une grande perte de temps. En réalité, valider la régression est une des valeurs ajoutées les plus importantes des tests automatisés. Les tests de non régression automatisés vous assurent à n’importe quel moment que votre logiciel fonctionne, sans effort additionnel.

«C’est intéressant tout ça, mais ça ne s’applique pas à notre situation»

En fait, cela s’applique à toutes les entreprises faisant du développement logiciel. Si les leaders mondiaux comme Google, Microsoft et Facebook réussissent à automatiser les tests de leurs logiciels, alors vous pouvez définitivement automatiser les vôtres. Si vous avez de la difficulté à tester votre logiciel, c’est simplement parce que votre architecture n’a pas été conçue en fonction d’être testable. L'architecte logiciel Michael Feathers propose une approche très intéressante à ce problème dans son livre Working Effectively with Legacy Code. Il explique comment passer d’un système «patrimonial» à un système testable et facile à maintenir. Je vous recommande cette lecture pour débuter votre processus!

J’aimerais conclure en vous partageant cette excellente citation de Félix-Antoine Bourbonnais qui décrit bien ce que je pense des tests : «Tu n’es pas payé à faire des tests? Tu n’es pas payé non plus à créer des bogues!»