Ton code fonctionne. Mais est-ce qu’on peut le tester ? Ou faut-il avoir un diplôme en magie noire pour le modifier sans tout casser ? Regarde l’exemple en image (en bas du post) : Un IngredientService simple en apparence. Mais en pratique ? → Une dépendance à un repository → Un logger à injecter → Et un test unitaire à écrire pour éviter les régressions Sans injection de dépendances, c’est l’enfer à tester. Tu dois lancer la moitié de l’app, brancher une base, prier pour que ça passe. Mais ici ? → Pas de DB → Pas de setup compliqué → Juste des mocks et du focus sur la logique métier Ce n’est pas juste du bon code. C’est du code testable. Et ça change tout. Parce que coder sans penser aux tests, c’est comme construire sans plan : Tu peux y arriver, mais le jour où tu veux bouger un mur… bon courage. Un code testable, c’est un code : → Prédictible → Modulable → Qui te donne confiance lors des refactos Et non, ce n’est pas réservé aux projets propres pour GitHub. C’est ce qui fait survivre ton code. Même à toi-même dans 6 mois. Et toi ? Tu écris du code qu’on peut tester, ou qu’on évite d’ouvrir ?