Sur les projets neufs
Pour tous les projets neufs, nous pratiquons TDD, qui n'est pas un élément négociable (sauf rares cas). Plus précisément, nous pratiquons Outside-In Diamond TDD, qui offre une plus grande souplesse que la traditionnelle pyramide de tests, que nous considérons comme trop rigide.
Notre pain quotidien, c'est le test d'acceptation ou test fonctionnel. Il détaille les clauses du contrat que nous avons passé ensemble en de multiples affirmations que nous relirons périodiquement avec vous afin de nous 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. Nous leurs donnons 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 nous servent également en démonstration, lorsque nous livrons une itération.
Nous ne sommes pas contre l'utilisation de tests plus fins, comme les tests unitaires. Nous pensons qu'en grand nombre ils rigidifient le code en dissuadent le refactoring, pratique fondamentale chez nous. Aussi, nous ne les utilisons 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
Nous adoptons la définition de Michael Feathers. Le Code Legacy est tout code non-testé qui nous est confié. Dans les cas où nous acceptons 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
Nous garantissons qu'aucun bug ne reviendra après sa résolution. Pour cela nous utilisons 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 nous en soyons informés.
Enzo Sandré