Sto leggendo che sei del parere che i test unitari, proprio come gli oggetti SOLID, debbano avere "una ragione per rompere". È un obiettivo nobile, ma penso che scoprirai che in molti casi non è semplicemente fattibile. Uno di questi casi è qui, dove si ha un oggetto di dominio "ricco" (DDD distingue tra Entità e Oggetti valore, che comprendono entrambi il "modello di dominio") che è una dipendenza del sistema sotto test.
In queste situazioni, ho la filosofia che, dato l'oggetto dominio ha la sua copertura di test unitaria completa, confidando che l'oggetto funzionerà come progettato in un test unitario per un SUT diverso non necessariamente violare il test unitario. Se questo test dovesse interrompersi a causa di una violazione del dominio, mi aspetterei che anche il test dell'unità dell'oggetto dominio si interrompesse, portandomi verso qualcosa su cui indagare. Se il test unitario dell'oggetto del dominio era stato aggiornato correttamente come un test rosso, quindi reso verde con la modifica, e questo altro test non è riuscito, 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 tra loro e con i criteri di accettazione generali del sistema.
Pertanto, modellerei solo un oggetto dominio se detto oggetto dominio producesse "effetti collaterali" che non erano desiderabili da una prospettiva di testing unitario (cioè toccando risorse esterne come archivi dati), o se la logica dell'oggetto dominio era sufficientemente complesso che posizionarlo nello stato appropriato per il test diventa un ostacolo alla definizione e al superamento del test.
Questa diventa quindi la domanda guida; che è più facile? Per utilizzare l'oggetto dominio per lo scopo previsto all'interno del test o per deriderlo? Fare tutto ciò che è più facile, fino a quando non è più l'opzione più semplice, ad esempio quando un cambiamento funzionale interrompe il test del servizio in modo complesso; se ciò accade, quindi riscrivi il test per produrre un mock che esponga i requisiti funzionali dipendenti dal servizio, senza la complessità che lo infrange.
Comprendi che in entrambi i casi, dovrebbe esserci un test di integrazione che utilizza l'oggetto dominio reale inserito nel servizio reale che verifica l'interazione tra questi due a un livello più alto di astrazione (ad esempio, test, ad esempio, non solo la funzionalità dietro un endpoint del servizio, ma un proxy attraverso il quale l'oggetto del dominio viene serializzato e inviato).