Я читаю, что вы придерживаетесь мнения, что модульные тесты, как и объекты SOLID, должны иметь «одну причину для отказа». Это благородная цель, но я думаю, вы обнаружите, что во многих случаях это просто невозможно. Один из таких случаев здесь, где у вас есть «богатый» объект домена (DDD различает сущности и объекты-значения, которые оба составляют «модель домена»), который является зависимостью тестируемой системы.
В этих ситуациях у меня есть философия, которая, учитываяу предметного объекта есть свое собственное всеобъемлющее покрытие модульных тестов, и уверенность в том, что объект будет работать так, как это предусмотрено в модульном тесте для другой SUT, не обязательно нарушает модульный тест. Если этот тест будет сорван из-за критического изменения домена, то я бы ожидал, что и модульный тест объекта домена также будет сорван, что приведет меня к чему-то, что нужно исследовать. Если модульный тест объекта домена был правильно обновлен как красный тест, затем изменен зеленым, и этот другой тест не прошел, это тоже не обязательно плохо; это означает, что ожидания этого другого теста вступают в противоречие с новыми ожиданиями в отношении домена, и мне необходимо убедиться, что они оба согласны друг с другом и с общими критериями приемлемости системы.
Таким образом, я мог бы высмеивать объект домена только в том случае, если указанный объект домена вызывал «побочные эффекты», которые были нежелательны с точки зрения модульного тестирования (т. Е. Касались внешних ресурсов, таких как хранилища данных), или если логика объекта домена была достаточно сложной, чтобы перевод его в надлежащее состояние для теста становится препятствием для определения и прохождения теста.
Это тогда становится движущим вопросом; что проще? Использовать объект домена по его прямому назначению в тесте или издеваться над ним? Делать то, что проще, до тех пор, пока это не станет более легким вариантом, например, когда функциональное изменение усложняет тест службы; если это произойдет, тогда перепишите тест, чтобы создать макет, который выставляет функциональные требования, зависящие от сервиса, без сложности, которая его нарушает.
Поймите, что в любом случае должен быть интеграционный тест, в котором используется реальный объект домена, подключенный к реальной службе, который проверяет взаимодействие между этими двумя объектами на более высоком уровне абстракции (например, при тестировании не только функциональности, стоящей за службой). конечная точка, но прокси, по которому объект домена сериализуется и отправляется).