Une fois n’est pas coutume, nous allons parler d’informatique, plus particulièrement effectuer des tests.

Souvent, les tests sont considérés comme une perte de temps, source de frustration ou simplement inutiles, on va voir pourquoi c’est essentiel dans un projet et surtout pourquoi c’est super cool de faire des tests.

L’agilité

Dans un premier temps, parlons un peu méthodologie. Parmi les méthodologies de projets, il y a, entre autres les méthodes Agiles. Des gens pas très connus ont fait un manifeste. Voici deux auteurs que je trouve importants:

Robert C. Martin: auteur de livres autour des principes de développement et du “bon” code. (Lisez les, ses livres sont extrêmement pédagogiques !)
Kent Beck: il a juste “inventé” l’Extrem Programming (XP) et JUnit, un framework de tests pour l’environnement Java.

Dans ce texte, un ligne nous intéresse particulièrement:

Des logiciels opérationnels plus qu’une documentation exhaustive

Des logiciels opérationnels. Ça, c’est le plus important dans l’histoire. Qu’est ce qu’un logiciel opérationnel ? C’est:

un logiciel qui fonctionne comme on s’y attend;
un logiciel qui ne doit pas régresser au fil des versions;
un logiciel qui doit refléter les demandes du client.

Pour cela, on utilise un truc ennuyant qu’on appelle plus fréquemment les tests. Les tests font en général peur aux néophytes, à celleux qui apprennent la programmation ou simplement qui se lancent dans un projet seul·e contre tou·te·s, avec une idée dans la tête et peu de temps.

Les différents tests

Alors là, c’est encore plus chiant. Il existe plusieurs types de tests (liste non exhaustive):

Unitaires: on vérifie le fonctionnement d’une petite partie du programme. Ça peut être une fonction ou un objet.
D’intégration: au niveau suivant, il y a les tests d’intégration. Cela veut dire qu’on imbrique différentes briques testées de manière unitaire. Cela peut s’agir d’une classe d’objet, par exemple. Tant que ça imbrique, ça intègre.
Fonctionnels: les tests fonctionnels peuvent être considérés comme des tests d’intégration à grande échelle. L’objectif est de tester un cas d’utilisation et de vérifier son fonctionnement (nous y reviendrons un peu plus bas dans l’article).
De régression: on est presque au boss final. Réaliser des tests de régression est important dans un projet car tout peut casser à la moindre modification que vous y faites. Ils servent à tester les anciens fonctionnements du logiciel. Si ça fonctionne, tant mieux. Sinon tu mets le stagiaire dessus, sauf si c’est toi le stagiaire. Courage.
D’acceptance: là c’est Ganondorf. Il s’agit de tester l’interface de votre application afin de vérifier le bon fonctionnement de votre château de cartes et des événements qui y sont liés. Ils sont également là pour faire valider au client le bon fonctionnement du projet.

Différents types de tests pour vérifier le fonctionnement des différentes briques ajoutées à votre application, ils valident de A à Z votre logiciel.

Le joyau du back-end

Parlons un peu satisfaction. Être développeur·se n’est parfois pas satisfaisant, c’est même souvent frustrant quand on bloque sur un problème de noob pendant quatre heures et qu’ensuite on demande au lead et le gars résout ça en quelques minutes. Il paraît qu’on appelle ça l’expérience. Seulement voilà, si le lead dev il est expérimenté, c’est parce qu’il a fait ces conneries avant toi. Et ses plus grosses conneries, c’est avec les tests qu’il s’en aperçoit. Elles sont vicieuses, incidueuses et souvent invisibles. Un peu comme le monstre caché sous ton lit quand tu avais 6 ans.

Quand on est côté back, on peut être satisfait·e parce que notre partie du logiciel fonctionne sur Insomnia ou Postman. Sauf que la vraie satisfaction pour nous c’est de voir une petite série de √ verts s’afficher à l’écran.

Le Test Driven Development

Ou TDD pour les intimes. Il y a plusieurs termes qu’on devra voir plus tard, comme mobile first, db first, etc. On s’attarde aujourd’hui sur le TDD.

Le TDD est presque devenu une norme aujourd’hui. Mais de quoi s’agit-il ? En réalité, c’est très simple. C’est un processus de développement pour s’assurer du bon fonctionnement d’un use case ou d’une user story que nous allons développer ensuite.

Petit aparté sur les use cases avant:

Un use case est la traduction littéral de cas d’utilisation;
Un use case a une utilisation nominale (son fonctionnement normal);
Un use a un/des cas d’utilisation(s) ayant des flux alternatifs ou des exceptions;
Les use cases se font avant de développer.

Le TDD permet de vérifier chacun des cas alternatifs imaginés ainsi que du cas nominal. Je parle bien d’un cas nominal. Un use case ne doit faire qu’une seule et unique chose. Et comme les UC (abréviation de Use Case), les tests s’écrivent avant de développer. La raison est simple: si on code avant l’écriture des tests, nous serions influencés par notre code et nous pourrions aisément oublier des cas alternatifs. En somme, le TDD permet de s’assurer le bon fonctionnement d’un logiciel via les tests qui sont écrits avant l’écriture même du code source. On en revient à la phrase du début.

Il s’agit d’une méthode de travail importante à l’heure actuelle où les logiciels sont de plus en plus gros avec de plus en plus d’exigences métiers.

Conclusion

Les tests font partie intégrante du métier de développeur·se, quel que soit votre langage, votre spécialité (back ou front). Ils assurent le bon fonctionnement de l’application et donc des use cases qui y sont liées. Ce sont des trucs chiants, frustrants quand nous mettons plusieurs heures à écrire des tests, à réfléchir aux différents cas qui n’ont pas été imaginés mais terriblement satisfaisants quand ils passent tous verts. De plus, lorsque vous écrirez votre code, vous serez beaucoup plus rapide et efficient·e.

Les tests c’est bien, mangez en au matin au petit ‘dej.

Dans le prochain article, on verra comment pondre des tests unitaires, d’intégration et fonctionnels pour Node.js avec Mocha et Chai.