Chapitre 5.3.3
Environnement de développement et de tests

L'environnement de développement local

Un développeur ne peut pas travailler directement sur la production. Modifier du code en direct sur les serveurs qui servent les clients, c'est la garantie de provoquer des incidents. Chaque développeur dispose donc de son propre environnement local : une copie de l'environnement de production, adaptée pour qu'elle fonctionne sur son ordinateur. Le développeur peut y faire des erreurs, tester des idées et tout casser sans aucune conséquence pour les utilisateurs.

L'environnement de développement local, la "dev", comprend tout ce dont le logiciel a besoin pour fonctionner : exécution du code, bases de données, systèmes de cache... C'est pour ça que les développeurs ont besoin de machines puissantes avec pas mal de mémoire.

Bien que se rapprochant au maximum des environnements de production, les environnements de développement ont leurs subtilités :

• Les configurations ne sont pas les mêmes : temps de mise en cache, affichage explicite des erreurs etc...
• Ils intègrent des outils de debug, de tests et tout ce qu'il faut pour aider et améliorer la productivité.
• L'infrastructure n'est pas rigoureusement la même. Par exemple, si la production tourne dans le cloud, on va avoir en développement une infrastructure qui l'imite, mais qui n'est pas une copie fidèle.
• Il est branché sur les environnements de tests des partenaires, aussi appelés bacs à sable (sandbox). Ils peuvent avoir un comportement différent de la production.
• Les bases de données contiennent de fausses données anonymisées, en théorie représentatives des données de production.

Ces décalages expliquent en partie pourquoi parfois les développeurs se prennent la tête à comprendre un problème. Le fameux "mais ça marche chez moi".

L'environnement de tests local

L'environnement "test" est une variante de l'environnement de développement qui sert à faire tourner les tests automatisés. Ce sont des programmes qui vérifient que le code se comporte comme prévu.
Distinguer les deux environnements nous sert à mettre en place des outils différents et des doublures sur des parties de l'infrastructure. C'est comme au cinéma, on met en place un faux pour tromper le code. Ça permet des tests fiables et rapides.

Par exemple, en dev nous nous appuyons sur une vraie base de données alors qu'en test nous pouvons vouloir brancher notre code sur une fausse. Ça permet de plus facilement tricher et de provoquer les différents scénarios que l'on souhaite tester.

Deuxième exemple : lorsqu'on exécute les tests automatiques, ce qui arrive des dizaines de fois par jour, nous ne souhaitons pas envoyer d'emails aux clients. On va alors se brancher sur un faux service d'envoi d'emails.

Sans entrer dans le détail, le concept de "doublure" se décompose en plusieurs notions. Entre autres : mock, stub, fake, spy, dummy... Ce sont tous des outils qui permettent de retourner de fausses données, de simuler un système complet, d'analyser les interactions avec les systèmes sous-jacents etc...
Par abus de langage, 99% des développeurs utilisent "mock" pour désigner tout type de doublure.


Le concept de doublure est crucial en développement.
Quand tu entends parler de vieux code "legacy", de code pas maintenable et pas testable, qui ne "respecte pas les bonnes pratiques", c'est parce-que ce code n'a pas été pensé pour pouvoir être doublé ou accepter des doublures. Les doublures sont la principale raison qui nous pousse à mettre en place des architectures solides.
Quand tu nous entends parler d'hexagone, d'injection de dépendances et de leurs amis, ce n'est pas seulement pour l'amour du joli code. Ces pratiques permettent de rendre le code testable et fonctionnel sur l'environnement de test. Sans ça, on n'a aucun moyen, en dehors de tests manuels, pour se protéger de l'introduction d'un bug ou d'une régression. Les mises en production deviennent stressantes, on découvre des choses bizarres 6 mois plus tard. Ce n'est pas un projet sur lequel on prend du plaisir à travailler.


Dans la plupart des entreprises, on retrouve l'environnement de test à deux endroits :

1. Sur l'ordinateur de chaque développeur. Selon leurs habitudes de travail, les dev peuvent exécuter les tests des dizaines de fois par jour. En particulier s'ils adoptent la conception pilotée par les tests (Test Driven Development / TDD).
2. Lors de la phase d'intégration continue dont nous parlerons dans les prochains chapitres. Le code se doit d'être testé par les tests automatisés avant de pouvoir être fusionné et déployé sur les environnements en aval de la chaine.