If You Can't Test It…

On connaissait « If You Can’t Test It, Don’t Code It », qui enlève du boulot à tous ceux qui ne sauraient pas ou n'auraient pas les moyens de:

• trouver l'environnement de tests pertinent (ça peut être un problème de budget, de hardware, d'impossibilité d'atteindre une charge demandée…),
• écrire le test – automatisable – du bout de code qu'il sont censés développer (eh ben non, ce n'est pas toujours aussi évident qu'on le dit, figurez-vous),
• trouver le temps de lancer le test (mouarf).

Maintenant, inaugurons « If You Can’t Test It, Don’t Specify It », qui va enlever du boulot parmi les MOAs à celles qui n'ont pas envie de s'enfoncer dans des spécifications contradictoires ou lacunaires, spécifications qui ne seront de toute façon jamais testées en conformité : elles sont du genre à changer un peu avant que la recette ne commence.

Cette maxime « If You Can't… Just Don't » est bêtement une conséquence de la méthode Test-Driven pour les spécifications, et ma foi c'est une très bonne conséquence.

D'ailleurs ça donne une idée par contraposition : et si la MOE décidait de refuser un cahier des charges qui ne contient pas à la base une batterie automatisée de tests de haut niveau ? Je ne dis pas que la MOA devrait spécifier ces tests, hein, je dis qu'elle devrait les écrire.
C'est un gage de succès pour la réussite de l'action de la MOA, alors pourquoi ne serait-ce pas un élément contractuel pour la MOE ? Après tout, tout le monde souhaite que le projet aboutisse, non ?