Quelques réactions :
- Les I/O c’est trop lent pour les tests
- Quid si j’ai un use case avec 30 cas différents ?
- Déplacer la logique business dans les tests d’intégration c’est une très mauvaise idée
Je suis d’accord avec tout cela.
Ce que j’indique c’est que dans les couches Clean Archi...
[Domaine]
[Use cases]
[Adapters]
[Infra]
... je vois souvent le pattern qui consiste à nourrir la couche Adapters, pour rendre les tests des Use Cases plus rapides.
Ca revient à mocker la DB, les fichiers, les services, etc. Et ça ne sert qu’aux tests.
Mon point de vue c’est qu’il est encore bien plus élégant de nourrir le Domaine avec des abstractions qui ne dépendent d’aucun Adapter, et sont globalement data-driven uniquement.
Cela déplace effectivement la majorité des tests vers du pur unitaire, sans même déplacer ni mock, ni stub.
Il reste à tester les Use Cases en intégration, en condition réelle : les vrais Adapters utilisés en prod plutôt que du code accidentel.
Bref nourrissez le domaine, pas le framework.
#SoftwareEngineering