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.
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.
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.
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.
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.
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!»