Placer la barre plus haut avec le TDD

Histoire de jouer un peu plus avec les outils que j'ai essayé pour Yapsy et aussi pour expérimenter avec le TDD, je me suis lancé dans un mini projet, entièrement hébergé sur github et pour lequel j'ai essayé de respecter les principes du TDD dans les grandes lignes (plus ci-dessous). Le projet en lui même s'appelle baciphacs et n'est rien d'autre qu'un re-développement d'un petit bout de code que j'ai l'impression d'écrire à chaque poste où je suis passé: générer du code HTML (avec un peu de CSS dans les tags en plus) représentant un diagramme en barre. Ce genre "d'astuce" est rarement la "meilleure solution" mais permet de générer des visualisations à peu de frais et sans se soucier d'éventuels problèmes de réseaux ou de licences. Concernant le TDD, baciphacs en est sans doute un très mauvais exemple vu que ce n'est qu'un premier essai mais ça m'a permis de confirmer l'impression que j'avais sur cette méthode: elle est effectivement (et c'est connu je crois) complètement contre-intuitive mais elle met en avant des principes de design qui me semblent importants et vont bien plus loin que le fait de tester un logiciel. En tant que développeur je crois qu'on a souvent tendance à imaginer un programme en commençant par détailler son implémentation avec seulement une idée approximative de ce que seront ses entrées/sorties et sur lesquelles on reviendra dans la phase de test. Finalement c'est assez naturel et conforme au rapprochement entre l'activité de développeurs et la fascination pour les puzzles et la mécanique d'horlogerie qui est décrite dans The Mythical Man Month. Mais le TDD, en imposant d'écrire les tests avant de coder le programme lui-même, nous force à penser en premier et de façon très concrète au contexte dans lequel une fonction ou une classe sera utilisée (c'est le "setup" du test) puis à écrire très précisément son utilisation en terme d'entrée/sortie et d'API (le test lui-même) avant d'aller implémenter la mécanique de cette classe ou cette fonction. Ce renversement imposé permet de ré-équilibrer les priorités lors du développement et c'est certainement une très bonne chose dans le contexte des méthodes agiles qui mettent chaque développeur en position de "responsable" des fonctionnalités à la fois pour leur implémentation et leur design. Un point un peu plus mitigé c'est que le TDD fait passer énormément de temps à écrire des tests. C'est sans doute rentable (en qualité à court terme mais aussi en de temps de développement à moyen terme) mais l'effet immédiat fait tout drôle (même avec l'habitude d'écrire pas mal de tests).