Il n’est pas possible de lancer rapidement un logiciel et d’écrire des tests automatisés, encore moins utiliser test-driven development.

L'écriture de tests automatisés, ou mieux l'utilisation de TDD, c'est un peu le niveau minimum pour assurer de façon fiable la qualité pour un logiciel, en particulier sur le long terme.

L’idée, très répandue est que, pour faire de la qualité, cela prend nécessairement plus de temps. C’est le triangle Périmètre - Coût - Délais, avec la qualité comme variable d’ajustement implicite et non dite au milieu.

Trivialement, dans le lancement de produit ou les startups, on va faire "vite et sale": on va prioriser la vitesse de déploiement sur la qualité du code.

Cela ressemble à un choix rationnel. Du point de vue des décideurs non développeurs, cela paraît naturel d'avoir un arbitrage à faire entre vite et bien.

De nombreux développeurs défendent cette idée: je peux faire vite, ou bien, mais pas les deux.

Pourtant, nous sommes nombreux dans le métier à défendre une idée contre-intuitive. Non seulement on peut faire vite et bien, mais on va plus vite en faisant bien. Pas seulement à moyen ou long terme. A très court terme.

Il n'y a plus grand monde pour contester qu'une codebase saine et évolutive comporte des tests automatisés. Le premier facteur de qualité, c'est l'écriture de tests automatisés.

L'utilisation de TDD permet de créer une suite de tests peu coûteuses qui va améliorer la qualité du logiciel et de la codebase. La discipline TDD oblige à une conception minimaliste, qui va éviter d'écrire du code superflu. Elle permet de concevoir un code plus simple, plus évolutif et plus maintenable, car couvert par une suite de tests de non-régression.

Encore faut-il maîtriser la pratique, et l'avoir suffisamment travaillée pour en tirer les bénéfices. Cela implique de maîtriser d'autres compétences liées, qui ne sont pas simples à acquérir.

Sans maîtrise de ces compétences, il est plus coûteux de produire du logiciel de qualité.

En maîtrisant ces compétences, on fait mieux, plus vite.

Vous souhaitez travailler avec quel développeur, celui pour qui cela prend plus de temps de faire de la qualité ou celui qui va plus vite en faisant de la qualité ?