D'abord le test, ensuite le code, sur une plateforme SaaS

Le développement piloté par les tests, connu sous le nom de TDD (test-driven development), est une méthode où le test s'écrit avant le code qu'il vérifie. Martin Fowler la décrit en trois étapes. On écrit un test pour la fonction suivante, on écrit le code jusqu'à ce qu'il passe, et on améliore le code nouveau et ancien pour qu'il reste bien construit.

Les trois étapes se répètent en cycle, connu sous le nom de red-green-refactor : le test échoue (red), il passe (green) et le code est remis en ordre (refactor). Fowler ajoute qu'avant de commencer le cycle, on écrit une liste des cas à vérifier, et que l'on en traite un à la fois. La méthode ne concerne pas seulement les plateformes, mais elle y rapporte davantage, parce qu'elles vivent de nombreuses années et changent en permanence.

On écrit le test en premier parce qu'il prouve qu'il peut échouer. Un test écrit après le code passe souvent du premier coup, et personne ne sait s'il aurait jamais attrapé une erreur. Quand on le voit échouer d'abord, on sait qu'il vérifie vraiment quelque chose.

Il y a un second avantage. Pour écrire le test, la fonction doit être décrite avec précision : ce qu'elle reçoit, ce qu'elle renvoie, ce qui se passe quand quelque chose tourne mal. On voit ainsi tôt ce qui manque aux besoins, quand la correction coûte une question et non une refonte. C'est pourquoi la méthode va avec l'analyse des besoins avant le code.

Il faut beaucoup de petits tests et peu de grands. C'est l'idée de la pyramide de tests (test pyramid), telle que Fowler la formule : bien plus de tests de bas niveau que de tests qui passent par l'écran. Au milieu se trouve un niveau de tests qui vérifient l'application à travers sa couche de services.

Fowler explique pourquoi les tests d'écran doivent rester peu nombreux : ils sont fragiles, coûteux à écrire et lents à exécuter. Il note aussi une exception. Si les tests de haut niveau sont rapides, fiables et peu coûteux à modifier, les tests de bas niveau ne sont pas nécessaires. En pratique, peu de tests reproduisent l'usage réel, et les petits font la plus grande partie du travail.

Nous suivons le même ordre pour chaque fonction. L'ordre est court et toujours respecté :

1. Le besoin est écrit et approuvé. Chaque fonction découle des besoins écrits de la première étape.

2. Le test est écrit et il échoue. Nous vérifions qu'il échoue pour la bonne raison.

3. Le code est écrit jusqu'à ce que le test passe. On n'écrit rien qu'un test ne demande.

4. Le code est remis en ordre. Après chaque changement, les tests sont relancés.

5. La fonction est vérifiée dans le navigateur. Nous l'ouvrons comme un utilisateur et la comparons au plan approuvé.

Chaque étape n'avance que lorsque tous les contrôles passent. Notre outil Planner applique cet ordre quand il construit une application à partir d'une spécification écrite, et nous le décrivons dans l'étude de cas de Planner. L'essentiel est que les tests ne sont pas assouplis pour passer : si un contrôle échoue, c'est le code qui est corrigé.

Un test est une phrase tirée des besoins, écrite de façon à ce qu'un programme puisse la vérifier. Si le tableau des droits dit qu'un opérateur n'approuve pas les demandes, le test démarre en tant qu'opérateur, essaie d'approuver une demande et attend un refus. Avant l'écriture du code, le test échoue, car le refus n'existe pas encore.

Ensuite, on écrit le code qui refuse l'approbation, et le test passe. Si quelqu'un modifie la règle par erreur plus tard, le même test échoue aussitôt, avant que le changement n'atteigne les utilisateurs. Les besoins que vous avez approuvés restent ainsi actifs après la livraison, et pas seulement sur le papier.

Quand une erreur est trouvée, on écrit d'abord un test qui la reproduit. Le test échoue avant la correction et passe après. La même erreur ne peut donc pas revenir sans qu'un contrôle l'attrape, et chaque correction laisse derrière elle une protection permanente.

Cela vaut aussi pour ce que trouve l'équipe d'agents qui examine le projet terminé pour y chercher des erreurs, des problèmes d'utilisabilité et de sécurité. Chaque constat confirmé est corrigé de la même façon. Nous expliquons la démarche dans l'étude de cas des agents de qualité et de sécurité. Un bon exemple est la sécurité des droits, que nous décrivons dans l'article sur les rôles et les droits dans un SaaS.