Sur les projets neufs
Pour tous les projets neufs, je pratique TDD, qui n'est pas un élément négociable (sauf rares cas). Plus précisément, je pratique Outside-In Diamond TDD, qui offre une plus grande souplesse que la traditionnelle pyramide de tests, qui doit être désapprise par la profession.
Notre pain quotidien, c'est le test d'acceptation isolé ou test fonctionnel. Il détaille les clauses du contrat que nous avons passé ensemble en de multiples affirmations que je reprendrai périodiquement avec vous afin de m'assurer d'avoir bien cerné votre besoin.
Les tests contractuels ou d'intégration, décrivent le comportement que nous avons fixé ensemble au début d'une itération. Je leur donne une valeur juridique, ces tests valident la conformité des travaux à votre demande initiale.
Les tests de plus haut niveau (smoke tests, end-to-end tests) viennent démontrer le bon fonctionnement de la solution en interaction avec le monde extérieur. Ils me servent également de démonstration, lorsque je vous livre une itération.
Je ne suis pas contre l'utilisation de tests plus fins, comme les tests unitaires. Ils ont hélas été trop utilisés par une partie de la profession, provoquant la rigidification du code et dégoûtant une partie des développeurs de l'écriture de tests. Aussi, je les utilise que sur des parties critiques du code, où la manière de procéder importe autant que le résultat obtenu (performances, algorithme précis, cryptographie, etc.).
Sur les projets legacy
J'adopte la définition de Michael Feathers. Le Code Legacy est tout code non-testé qui m'est confié sans pouvoir partir rapidement à la poubelle. Dans les cas où j'accepte de reprendre un tel code, il est exclu, sauf si votre budget est colossal, de l'assainir complètement d'un coup. Le code ajouté ou modifié sera testé comme du code neuf. Le code préexistant sera sécurisé à l'aide de tests plus grossiers (smoke test) selon vos besoins, le niveau de confiance que vous souhaitez et votre budget.
Une fois repris et étayé, votre code devra être progressivement assaini. Un budget mensuel devra être établi à ce titre, il ne servira qu'à réduire l'endettement de votre application, donc à faciliter les développements futurs. Un bon budget de maintenance représente une charge non-négligeable sans pour autant gréver votre rentabilité. Il n'est pas de l'argent investi à perte, mais bien la garantie que le logiciel dans lequel vous avez investi tant d'efforts ne décède pas un beau matin, trop endetté pour pouvoir évoluer au rythme de vos besoins.
En cas de défaut
Je garantis qu'aucun bug ne reviendra après sa résolution. Pour cela j'utilise les tests de défaut. Pour chaque bug constaté, un test est écrit afin de le reproduire. Puis le code est modifié afin de faire passer ce test. Ainsi le bug corrigé ne peut pas revenir sous cette forme sans que je n'en sois informé.
Enzo Sandré