Vous êtes-vous déjà retrouvé dans l’une de ces situations ?
Votre système d’exploitation plante.
Votre logiciel de traitement de texte perd les 50 pages de rapport que vous venez de taper.
Dans un jeu, vous arrivez à passer à travers un mur !
Si ces exemples vous sont familiers, c’est que vous avez déjà compris l’intérêt des tests... et vous êtes au bon endroit ! Alors, bienvenue dans ce cours. 😄
En effet, une des grandes préoccupations des créateurs de logiciels est d’être certains que leur application informatique fonctionne et surtout qu’elle fonctionne dans toutes les situations possibles.
Et, pour en être sûr, il faut faire des tests.
Qu’est-ce qu’un test ?
Faire un test, c’est vérifier qu’une partie de son logiciel fonctionne comme attendu. Si vous avez déjà développé, vous savez que la transformation d’une idée ou d'un besoin en code informatique peut être complexe et sujette à erreur ou interprétation.
En voici quelques raisons :
Le besoin peut avoir été mal ou vaguement défini, que ce soit votre besoin ou celui d’un client. En conséquence, vous ne le développez pas comme il le faut.
De la même façon, le besoin peut avoir été mal compris. Résultat : le logiciel ne correspond pas à ce qui est attendu.
Vous avez fait des erreurs dans le code qui font que le logiciel plante, ou pire, qu’il ne fonctionne pas comme il faut ! Vous imaginez si le logiciel de votre banque vous retirait à chaque fois le double de ce que vous payez ?
Ou encore plus insidieux, tout fonctionne bien, sauf dans des cas limites du logiciel. Par exemple, vous développez une calculatrice, elle fonctionne bien, sauf dans le cas où vous tentez de diviser quelque chose par zéro. Et là, boum ! 😵
Alors, comment s’assurer que le besoin correspond exactement à ce qui a été développé ? Ou encore, comment s’assurer que la saisie d'une valeur non prévue par le développeur ne provoque pas un plantage, voire une faille de sécurité ?
Les tests comme un filet de sécurité
Vous l’aurez sans doute deviné d'après le titre de ce chapitre : il faut faire des tests ! 😜
Les tests vont nous permettre d'être confiants et de nous assurer qu’un changement ne casse pas une fonctionnalité existante.
Imaginez : vous amenez votre voiture chez le garagiste, car la fenêtre ne ferme plus. Il la répare, mais le levier de vitesse ne fonctionne plus à la suite de son intervention. J’imagine que vous allez considérer qu'il est incompétent (et je ferais pareil !) et que vous ne lui donnerez plus votre voiture à réparer. 😧
En informatique, l'apparition d'un nouveau problème à la suite d'une correction est fréquente, malheureusement. La façon dont nous créons nos logiciels fait que les éléments sont très dépendants les uns des autres. Par conséquent, réparer un problème sur le formulaire d’inscription d’un site d’e-commerce va peut-être casser le paiement de la commande !
C’est le syndrome d’un code fragile. Une modification à un endroit a un impact à un autre endroit. Et là, que vont penser votre chef ou votre client ? Oui oui, comme vous, avec votre garagiste ! 😜
Faire des tests va non seulement nous permettre d'avoir confiance en la fiabilité de notre code, mais cela va aussi nous permettre d’avancer plus rapidement. En effet, en étant plus confiant, vous avez moins peur de casser quelque chose en développant de nouvelles fonctionnalités ! De plus, aujourd’hui, sur un marché très concurrentiel où tout va très vite, il faut pouvoir être réactif et innover le premier. Beaucoup de grosses entreprises n’arrivent d’ailleurs plus à innover parce qu’elles ne parviennent plus à avancer rapidement.
Avoir une batterie de tests est également un élément fondamental lorsqu’il s’agit de réduire la dette technique. La dette technique est un combat perpétuel que tout développeur doit mener. Mais comment remanier ("refactoring", en anglais) un code tout en étant certain de ne pas introduire de régression ?
Eh oui ! Les tests constituent un filet de sécurité, vous protégeant de toute régression. Avec des tests, vous redevenez libre ! Libre de changer le nom d’une méthode, de simplifier tel ou tel code, d’extraire des méthodes pour avoir un code propre, d’optimiser les temps d’exécution, etc. Bref, vous réduisez la dette technique. ☺️
Merci les tests !
Et dans la vraie vie ?
Vous commencez à vous rendre compte que les tests sont indispensables pour tout développeur désireux de créer un logiciel qui se respecte ? Vous voulez un exemple plus concret ?
Vous connaissez peut-être l’histoire du vol 501 d’Ariane 5 ?
Les ingénieurs se sont passé des tests pour économiser 800 000 francs (oui, c'étaient des francs, à l'époque 😅 ). Ils n’ont donc pas vérifié que le système de navigation d’Ariane 4 était compatible avec le matériel d’Ariane 5. En fin de compte, plus de 370 millions de dollars de matériel ont explosé.
Tout cela pour s’économiser des tests ?
Et il y a plein d’autres histoires...
Knight Capital a perdu 440 millions de dollars en une journée parce que le logiciel faisait l’inverse de ce qu’il devait faire. Je n’aurais pas aimé être à la place de ceux qui ont développé l’algorithme sans l'avoir testé comme il faut.
Dernièrement encore, nous avons vu des iPhone qui plantaient rien qu’en naviguant sur une page web.
À titre personnel, j’ai vu des entreprises qui tremblaient à chaque mise en production, car personne n’était vraiment sûr de ce qui allait se passer. Difficile de croire qu’un logiciel puisse autant échapper au contrôle des développeurs.
Globalement, je dirais que faire des tests ne semble pas être le fort des développeurs, mais les choses s'améliorent. J'espère que vous y contribuerez grâce à ce cours !
Aujourd’hui, les grosses entreprises ne peuvent plus se permettre d'avoir leurs services qui ne fonctionnent pas 99 % (voire 100 %) du temps. Je pense que vous êtes comme moi et que vous râlez dès que vous avez une coupure d'électricité ou d'internet.
Des entreprises, comme Amazon ou Netflix, passent leur temps à faire des évolutions ou des corrections, mais ne peuvent pas se permettre d'interrompre leurs services. Cela peut représenter jusqu'à des centaines de mises en production par jour. 😱
La seule solution est donc de tester en permanence chaque fonctionnalité. Ces entreprises poussent même leurs tests à l'extrême en éteignant volontairement des serveurs, ou bien en rendant KO des connexions réseaux, afin de vérifier la résilience de leurs solutions. Pour ce faire, elles utilisent des outils qui vont provoquer de vraies pannes aléatoires.
Qui oserait faire cela sur son propre logiciel ? Il faut une sacrée dose de confiance !
Et pour se le permettre, il faut énormément de tests, et des tests utiles !
À quel moment faut-il faire des tests ?
La réponse idéale serait : tout le temps ! Il y a même des façons de développer (que l’on abordera un peu plus tard dans ce cours) qui incitent à commencer par écrire un test avant même de développer.
Donc, si vous créez une fonctionnalité, vous devez faire des tests.
Mais si vous arrivez sur un projet déjà développé sans aucun test (oui, cela arrive 😀 ), sur lequel il faut faire de la maintenance applicative, c’est aussi le moment de faire des tests.
En effet, si vous corrigez un bug à un endroit, vous devez être certain de ne pas introduire de régression. Pour cela :
Dans un premier temps, vous pouvez écrire un test pour valider ce qui fonctionne déjà.
Ensuite, il faut écrire un test pour reproduire l’erreur que vous devez corriger (bien sûr, ce test échouera).
Enfin, vous allez corriger le bug et vous validerez que les tests précédents continuent d’être bons.
Serein, confiant… Fini le stress, les pellicules et les démangeaisons cutanées. Grâce aux tests, vous économiserez même votre santé ! 😄
Convaincu ? Alors on se retrouve dans le chapitre suivant...
