Czytam, że według ciebie testy jednostkowe, podobnie jak obiekty SOLID, muszą mieć „jeden powód do zerwania”. To szlachetny cel, ale myślę, że przekonasz się, że w wielu przypadkach jest to po prostu niewykonalne. Jednym z tych przypadków jest tutaj, w którym masz „bogaty” obiekt domeny (DDD rozróżnia jednostki i obiekty wartości, które oba obejmują „model domeny”), który jest zależnością testowanego systemu.
W takich sytuacjach mam podaną filozofięobiekt domeny ma swój własny kompleksowy zasięg testu jednostkowego, ufając, że obiekt będzie działał tak, jak został zaprojektowany w teście jednostkowym dla innego SUT, niekoniecznie narusza test jednostkowy. Gdyby ten test został zerwany z powodu przełomowej zmiany w domenie, oczekiwałbym również, że test jednostkowy obiektu domeny również się zepsuje, co doprowadzi mnie do czegoś do zbadania. Jeśli test jednostkowy obiektu domeny został poprawnie zaktualizowany jako test czerwony, a następnie zmienił się na zielony wraz ze zmianą, a ten drugi test nie powiódł się, niekoniecznie jest to zła rzecz; oznacza to, że oczekiwania tego drugiego testu są sprzeczne z nowymi oczekiwaniami dla domeny, i muszę upewnić się, że oba zgadzają się ze sobą i nadrzędnymi kryteriami akceptacji systemu.
W związku z tym wyśmiewałbym obiekt domeny tylko wtedy, gdy wspomniany obiekt domeny wywoływałby „skutki uboczne”, które byłyby niepożądane z perspektywy testów jednostkowych (tj. Dotykając zewnętrznych zasobów, takich jak magazyny danych), lub gdyby logika obiektu domeny była wystarczająco złożona umieszczenie go w odpowiednim stanie do testu staje się przeszkodą w zdefiniowaniu i zdaniu testu.
To staje się wtedy głównym pytaniem; co jest łatwiejsze? Używać obiektu domeny zgodnie z jego przeznaczeniem w teście, czy wyśmiewać? Rób to, co jest łatwiejsze, dopóki nie będzie to już łatwiejsza opcja, na przykład gdy zmiana funkcjonalna przerywa test usługi w złożony sposób; jeśli tak się stanie, przepisz test, aby utworzyć próbkę, która ujawnia wymagania funkcjonalne zależne od usługi, bez złożoności, która ją psuje.
Zrozum, że tak czy inaczej, powinien istnieć test integracji wykorzystujący prawdziwy obiekt domeny podłączony do prawdziwej usługi, który testuje interakcję między nimi na wyższym poziomie abstrakcji (np. Testowanie, na przykład, nie tylko funkcjonalności usługi) punkt końcowy, ale serwer proxy, przez który obiekt domeny jest serializowany i wysyłany).