Чи повинні ми знущатися над сутностями та цінними об’єктами, коли робимо DDD?

Після прочитання кількох статей про Newable проти контурних об'єктів і як ці поняття відносяться до послуг для DDD, організаціям та об'єктам вартості, я залишився з деякими сумнівами про використання newables в моєму коді , особливо в моїх модульних тестах.

Основними кандидатами для нових предметів були об'єкти Entities and Value, тобто, замість того, щоб вводити ці залежності в інші об'єкти, слід просто newекземпляри цих об'єктів і використовувати їх безпосередньо в коді.

Однак добрі практики DDD пропонують покладати відповідальність на об'єкти та об'єкти цінності, якщо вони вважаються доцільними. Таким чином, об'єкти та об'єкти цінності закінчуються серйозною діловою логікою.

Тепер, якщо служба діє на об'єкті чи об'єкті значення, чи варто мені знущатися над об'єктом чи об'єктом цінності та передавати макет службі (глузування вимагатиме interfaceзначення об'єктів чи об'єктів, які, схоже, виступають проти)?

Або я повинен просто newоб’єкт / цінність об'єкта і передавати конкретну реалізацію сервісу, таким чином, порушуючи принцип одиничного тестування тестування лише однієї одиниці?

Я читаю, що ви вважаєте, що одиничні тести, подібно до об'єктів SOLID, повинні мати "одну причину зламу". Це благородна мета, але я думаю, що ви побачите, що в багатьох випадках це просто неможливо. Один із таких випадків є тут, коли у вас є "багатий" доменний об'єкт (DDD розмежовує об'єкти та об'єкти цінності, які обидва складають "доменну модель"), що є залежністю від тестуваної системи.

У цих ситуаціях я маю таку філософію, яку данооб’єкт домену має власне всеохоплююче покриття тестових одиниць, довіряючи, що об’єкт буде працювати так, як було розроблено в одиничному тесті для іншого SUT, не обов'язково порушує тест одиниці. Якби цей тест був перерваний через зміну домену, то я б очікував, що тест одиничного об'єкта домену також зламається, що приведе мене до чогось досліджувати. Якщо тест одиниці об’єкта домену був належним чином оновлений у вигляді червоного тесту, а потім змінено зеленим кольором, а цей інший тест потім не вдався, це теж не обов'язково; це означає, що очікування цього іншого тесту суперечать новим очікуванням домену, і мені потрібно переконатися, що вони обоє згодні між собою та загальними критеріями прийняття системи.

Як такий, я би знущався над об'єктом домену лише у тому випадку, коли зазначений доменний об’єкт викликав "побічні ефекти", які були небажані з точки зору тестування одиниць (тобто торкання зовнішніх ресурсів, таких як сховища даних), або якщо логіка об'єкта домену була досить складною, розміщення його у належному стані для тесту стає блокуванням для визначення та проходження тесту.

Це потім стає рушійним питанням; що легше? Використовувати об’єкт домену за призначенням у межах тесту чи знущатися над ним? Робити те, що простіше, доки це не стане більш простим варіантом, наприклад, коли функціональна зміна розбиває тест служби комплексно; якщо це трапиться, перепишіть тест, щоб створити макет, який викриває функціональні вимоги, залежать від служби, без складності, яка порушує його.

Зрозумійте, що в будь-якому випадку повинен бути тест на інтеграцію, який використовує об'єкт реального домену, підключений до реальної служби, який тестує взаємодію між цими двома на більш високому рівні абстракції (наприклад, тестування, наприклад, не тільки функціональності служби) кінцева точка, але проксі, через який об'єкт домену серіалізується та надсилається).

Довіряючи залежному класу, що він працює належним чином, сподіваючись, що це не вдасться виконати деякі одиничні тести, коли щось там не працює, то це повинно бути перевірено дуже добре . Можливо, відсутні якісь важливі одиничні тести? Може бути неперевірений випадок, який створив би помилку, яка буде створена в моєму початковому класі тестування, і не потрапила б у залежний клас.

Тож, на мою думку, для одиничних тестів слід знущатися із залежних класів. Якщо цього не зробити, то це його інтеграційний тест.