Saya membaca bahwa Anda berpendapat bahwa unit test, seperti objek SOLID, harus memiliki "satu alasan untuk dilanggar". Itu adalah tujuan mulia, tetapi saya pikir Anda akan menemukan bahwa dalam banyak kasus itu sama sekali tidak layak. Salah satu kasus tersebut ada di sini, di mana Anda memiliki objek domain "kaya" (DDD membedakan antara Entitas dan Objek Nilai, yang keduanya terdiri dari "model domain") yang merupakan ketergantungan sistem yang sedang diuji.
Dalam situasi ini, saya memiliki filosofi yang diberikanobjek domain memiliki cakupan tes unit komprehensif sendiri, percaya bahwa objek akan bekerja seperti yang dirancang dalam tes unit untuk SUT yang berbeda tidak selalu melanggar tes unit. Jika tes ini rusak karena perubahan pada domain, maka saya akan berharap tes unit objek domain juga rusak, menuntun saya ke arah sesuatu untuk diselidiki. Jika pengujian unit objek domain telah diperbarui dengan benar sebagai tes merah, kemudian dibuat hijau dengan perubahan, dan tes lainnya ini gagal, itu tidak selalu merupakan hal yang buruk juga; itu berarti bahwa harapan dari pengujian yang lain ini bertentangan dengan harapan baru untuk domain, dan saya harus memastikan keduanya setuju satu sama lain dan kriteria penerimaan yang menyeluruh dari sistem.
Karena itu, saya hanya akan mengejek objek domain jika objek domain tersebut menghasilkan "efek samping" yang tidak diinginkan dari perspektif unit-testing (yaitu menyentuh sumber daya eksternal seperti penyimpanan data), atau jika logika objek domain cukup kompleks sehingga menempatkannya dalam kondisi yang tepat untuk ujian menjadi penghalang untuk menentukan dan lulus ujian.
Itu kemudian menjadi pertanyaan pendorong; mana yang lebih mudah? Untuk menggunakan objek domain untuk tujuan yang dimaksudkan dalam pengujian, atau mengejeknya? Lakukan yang mana yang lebih mudah, sampai bukan lagi pilihan yang lebih mudah, seperti ketika perubahan fungsional memecah pengujian layanan dengan cara yang kompleks; jika ini terjadi, maka tulis ulang tes untuk menghasilkan tiruan yang memperlihatkan persyaratan fungsional yang bergantung pada layanan, tanpa kerumitan yang memecahkannya.
Memahami bahwa bagaimanapun juga, harus ada tes integrasi yang menggunakan objek domain nyata dicolokkan ke layanan nyata yang menguji interaksi antara keduanya pada tingkat abstraksi yang lebih tinggi (seperti pengujian, misalnya, tidak hanya fungsi di balik layanan endpoint, tetapi proxy yang melaluinya objek domain diserialisasi dan dikirim).