Non seulement les tests unitaires facilitent la conception, mais c’est l’un de leurs principaux avantages.
L'écriture test-first élimine la modularité et la structure de code propre.
Lorsque vous écrivez votre test de code en premier, vous constaterez que toutes les "conditions" d'une unité de code donnée sont naturellement poussées vers des dépendances (généralement via des imitations ou des stubs) lorsque vous les supposez dans votre code.
"Étant donné la condition x, attendez le comportement y", deviendra souvent une souche à fournir x
(ce qui est un scénario dans lequel le test doit vérifier le comportement du composant actuel) et y
deviendra une simulation, un appel qui sera vérifié à la fin du test (à moins qu'il ne s'agisse d'un "devrait retourner y
", auquel cas le test vérifiera simplement la valeur de retour de manière explicite).
Ensuite, une fois que cette unité se comporte comme spécifié, vous écrivez les dépendances (pour x
et y
) que vous avez découvertes.
L'écriture de code propre et modulaire est donc un processus très simple et naturel. Sinon, il est souvent facile de brouiller responsabilités et comportements de couple sans s'en rendre compte.
Écrire des tests plus tard vous dira quand votre code est mal structuré.
Lorsque rédiger des tests pour un élément de code devient difficile parce qu'il y a trop d'éléments à bloquer ou à imiter, ou parce que les éléments sont trop étroitement liés, vous savez que vous devez apporter des améliorations à votre code.
Lorsque "changer de test" devient un fardeau, car il y a tellement de comportements dans une même unité, vous savez que vous devez apporter des améliorations à votre code (ou simplement à votre approche de la rédaction de tests - mais ce n'est généralement pas le cas dans mon expérience). .
Lorsque vos scénarios deviennent trop compliquées ( « si x
et y
et z
puis ... ») parce que vous avez besoin de plus abstrait, vous savez que vous avez des améliorations à apporter dans votre code.
Lorsque vous vous retrouvez avec les mêmes tests dans deux appareils différents en raison de la duplication et de la redondance, vous savez que vous devez apporter des améliorations à votre code.
Voici une excellente conférence de Michael Feathers démontrant la relation très étroite qui existe entre testabilité et conception en code (publié à l'origine par displayName dans les commentaires). La conférence aborde également certaines des plaintes communes et des idées fausses sur la bonne conception et la testabilité en général.