Bonne remarque :) Je ne suis pas du tout expert sur le sujet, donc ma réponse est à prendre avec des pincettes. Pour moi c'est une question de nuance. Certaines classes n'auront aucun TU directement associés, car elles seront complétement couvertes par d'autres tests. D'autres seront complètement couvertes par des tests spécifiques si leur fonctionnalité est complexe.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/

@xtrembaker, lorsque j'ai une méthode un peu tricky comme tu dis, c'est surrement un élément important/complexe de ton business. Je te recommande alors de sortir cet élément dans une classe distincte dédié à l'implémentation de cette algo. ca te permet donc de dégager une partie "complexe" de ta classe mère, de sans doute mieux respecter le principe de single responsability
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)

Globalement, je trouve qu'il est préférable de partir des Use Case en TDD et de faire emerger les ports quand on a besoin d'interagir avec l'extérieur.

Pour approfondir, je pense que tu trouveras des gens intéressés par ces questions sur le slack de Wealcome de Michaël Azerhad.

join.slack.com/...

Merci Marc pour ce lien