Blogue

Des 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 le mythe plus en profondeur

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. Pourquoi avoir besoin de démarrer votre logiciel pour savoir si votre méthode fonctionne? Lorsque vous trouvez un bogue, vous avez seulement à 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! 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.

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. Ces tests vous assurent à n’importe quel moment que votre logiciel fonctionne, sans effort additionnel.

C’est intéressant tout ça, mais cela ne s’applique pas pour nous

En fait, cela s’applique à toutes les entreprises ayant du développement logiciel. Si les leaders mondiaux comme Google, Microsoft, Facebook et autres réussissent à automatiser les tests de leurs logiciels, alors vous pouvez définitivement automatiser le vôtre. 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. 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 facilement maintenable.

J’aimerais conclure en vous partageant cette excellente citation de Félix-Antoine Bourbonnais :

Tu n’es pas payé à faire des tests? Tu n’es pas payé non plus à créer des bogues!

 

Partagez cette publication

Commentaire (0)

Laisser un commentaire