Tests unitaires - test ou conception?

Karl Seguin vient de publier un livre, Foundations of Programming, disponible en téléchargement. J'ai feuilleté un peu le PDF, et notamment le paragraphe intitulé "Why Wasn't I Unit Testing 3 Years Ago?" - littéralement "Pourquoi n'utilisais-je pas les tests unitaires il y a 3 ans?".

I had misconception about the goals of unit testing. As I’ve already said, unit testing does improve the quality of a system, but it’s really all about making it easier to change / maintain the system later on. Furthermore, if you go to the next logical step and adopt Test Driven Development, unit testing really becomes about design. To paraphrase Scott Bellware, TDD isn't about testing because you're not thinking as a tester when doing TDD – you’re thinking as a designer.

Lorsqu'on écrit un test unitaire, selon Karl Seguin, on ne porte pas la casquette du testeur, mais bien celle du concepteur. L'idée va à l'encontre de l'intuition, bien sûr: dans "test unitaire", il y a "test", et les tests c'est d'habitude plutôt la queue du train, à l'opposé de la conception.

Mais l'idée est non seulement rafraîchissante: elle sonne juste! Chez Ableton, nous n'utilisons pas les tests unitaires de manière systématique, mais cela ne m'empêche pas d'en avoir une petite collection dans mon coin, et je dois bien dire que celles de mes fonctionnalités qui sont testées de cette manière sont aussi matérialisées par les classes les plus indépendantes et les mieux conçues. En effet, comment tester une classe qui en requiert 14 autres? Et notez bien qu'on peut retirer ces bénéfices même sans pratiquer le TDD, c'est-à-dire sans écrire ses tests avant le code à tester.

Je n'ai pas lu le reste de l'ouvrage, mais je pense qu'il contient quelques de bons conseils. Amis de Shakespeare, jettez-y un coup d'œil.