Sto leggendo che ritieni che i test unitari, proprio come gli oggetti SOLID, debbano avere "un motivo per rompere". È un obiettivo nobile, ma penso che scoprirai che in molti casi semplicemente non è fattibile. Uno di questi casi è qui, in cui si dispone di un oggetto di dominio "ricco" (DDD distingue tra Entità e Oggetti valore, che entrambi comprendono il "modello di dominio") che è una dipendenza del sistema in prova.
In queste situazioni, ho la filosofia che, datal'oggetto dominio ha una propria copertura di unit test completa, confidando che l'oggetto funzionerà come previsto in un unit test per un SUT diverso non viola necessariamente il test unitario. Se questo test dovesse interrompersi a causa di una modifica del dominio, mi aspetterei che anche il test unitario dell'oggetto dominio si interrompesse, conducendomi verso qualcosa da indagare. Se il test unitario dell'oggetto dominio è stato aggiornato correttamente come test rosso, quindi reso verde con la modifica e questo altro test fallito, non è necessariamente una cosa negativa; significa che le aspettative di questo altro test sono in conflitto con le nuove aspettative per il dominio, e devo assicurarmi che entrambi siano d'accordo l'uno con l'altro e i criteri generali di accettazione del sistema.
In quanto tale, deriderei un oggetto di dominio solo se detto oggetto di dominio producesse "effetti collaterali" indesiderabili dal punto di vista del test di unità (cioè toccando risorse esterne come archivi di dati), o se la logica dell'oggetto di dominio fosse sufficientemente complessa che posizionarlo nello stato corretto per il test diventa un blocco stradale per la definizione e il superamento del test.
Questa diventa quindi la domanda guida; quale è più facile? Utilizzare l'oggetto di dominio per lo scopo previsto all'interno del test o deriderlo? Fare ciò che è più semplice, fino a quando non è più l'opzione più semplice, ad esempio quando una modifica funzionale interrompe il test del servizio in modo complesso; in tal caso, riscrivere il test per produrre una simulazione che esponga i requisiti funzionali dipendenti dal servizio, senza la complessità che lo interrompe.
Capire che in entrambi i casi, dovrebbe esserci un test di integrazione che utilizza l'oggetto di dominio reale collegato al servizio reale che verifica l'interazione tra questi due a un livello di astrazione più elevato (come il test, ad esempio, non solo la funzionalità dietro un servizio endpoint, ma un proxy attraverso il quale l'oggetto di dominio viene serializzato e inviato).