Le blog

Régisseur ! Lumière sur les tests, s’il vous plaît.

Si vous avez déjà essayé de “coder” quelque chose, vous savez qu’il n’est pas possible d’écrire du code comme on écrit un mail ou un article de blog. Il ne s’agit pas d’écrire du texte au kilomètre, mais d’assembler une série d’instructions dans le but de faire réaliser une action par un ordinateur.

Les développeurs, ne travaillent jamais sans tester. Tester est une partie intégrante du développement. Un développeur écrit quelques instructions puis vérifie qu’elles marchent comme il s’y attend. Dans ce processus, il s’agit de vérifier qu’il a bien compris comment l’ordinateur interprète les instructions qu’il lui donne.

Quand on écrit une ligne de code, il est impossible d’ignorer le test. Si on ne teste pas très tôt on trouvera très tardivement beaucoup d’erreurs d’interprétation. On sera ensuite obligé de faire des corrections qu’il faudra ensuite tester à nouveau et le cycle risque de durer ainsi très longtemps.

Le test est omniprésent pendant l’activité de programmation. Le développeur ne reste jamais lontemps sans tester. Il teste après avoir écrit quelques instructions seulement. À intervalles plus larges, quand une fonction est terminée, il teste à nouveau, mais avec plus de recul. Enfin, il faut encore traiter l’intégration entre les différentes parties du système.

Bref, on passe son temps à tester. Cela rappelle ce qu’écrivait F. Brooks dans The Mythical Man-Month: Essays on Software Engineering en 1975 : «For some years I have been successfully using the following rule of thumb for scheduling a software task: 1/3 planning, 1/6 coding, 1/4 component test and early system test and 1/4 system test, all components in hand.»

Un sixième du temps pour le développement contre une moitié pour les tests.

A ce stade on ne devrait plus dire du dév-eloppement, mais du test-eloppement logiciel.

Les tests sont du code.

Alors, programmer c’est tester… Bon.

Mais pourquoi programme-t-on ?

On programme pour automatiser des taches répétitives.

Puisque l’activité de test est extremement répétitive pourquoi ne pas programmer les tests ?

Finalement, tester c’est programmer. Cool.

Comment mettre en œuvre l’automatisation des tests ?

Il faut partir du fonctionnel. Que veut-on que le logiciel fasse ? Que veut-on que telle petite partie du code fasse ? Il est toujours possible de se poser cette question avant d’écrire le code. C’est même judicieux pour ne pas écrire directement du code idiot.

Pour écrire un test automatisé, il faut l’écrire en premier, c’est-à-dire, avant que le code applicatif n’ait été écrit.

Cela vous paraît peut être contre-intuitif. C’est en fait indispensable. Puisque le test est du code, il faut tester le test. Ainsi, on écrit le test en premier pour le test lui-même : on l’écrit puis on l’exécute pour vérifier qu’il joue bien son rôle de test, pour vérifier qu’il teste bien l’absence d’un comportement du logiciel.

Et maintenant, une page de publicité

Pour les développeurs qui ne connaissent pas cette technique, cela demande de l’entraînement. C’est un entraînement de n’écrire que le code nécessaire pour faire passer le test. C’est un entraînement de toujours revenir aux tests dès que l’on a écrit suffisament de code pour faire passer les tests existants.

Chez /ut7, nous sommes rompus à cet exercice et nous savons aussi transmettre cette pratique. N’hésitez pas à nous contacter, nous animons des formations, nous accompagnons les équipes de développeurs…

…nous faisons du testeloppement.