Не издевайтесь над правилом объектов домена?

Question

Самый опытный разработчик в моей нынешней команде установил несколько жестких правил, основанных на рекомендациях, которым мы должны следовать.Среди них «Вы никогда не издеваетесь над доменным объектом».Я спросил его, почему мы не можем, но у него никогда не было времени, чтобы дать мне правильный ответ.Теперь он уехал на неделю, и я достиг пика недоверия к этому правилу, вот моя ситуация.

У моего доменного объекта есть метод Update с несколькими параметрами, один из которых является интерфейсом для калькулятора.Затем он обновляет несколько полей, запускает калькуляторы и присваивает свои результаты некоторым другим полям.

Надлежащий модульный тест для самого метода Update достаточно длинный.

Теперь яесть некоторый кусок кода, который делает несколько вещей, а затем вызывает Update для такого объекта домена.

Обычно я высмеиваю объекты и просто проверяю, вызывается ли метод Update с правильными аргументами.Но теперь я должен проверить, правильно ли он вызывается, проверяя его поля и издеваясь над калькулятором, точно так же, как я это делал при модульном тестировании самого метода Update.И я должен делать это везде, где вызываются методы Update.Как весело будет, когда метод Update немного изменится, и каждый из этих тестов внезапно прекратится и нуждается в рефакторинге ... Я чувствую, что это правило похоже на выстрел в себя ...

Так что янужно знать, почему Вы никогда не издеваетесь над доменным объектом "?

Answer 1

Хотя Update(), вероятно, не такой приспособленный метод, как можно было бы ожидать от модели с расширенным доменом - что может повлиять на хрупкость теста - я согласен, что вы должны следовать совету "никогда не делай Х" с недоверием .

Если вы понимаете все последствия и знаете, что версия интеграционного теста будет менее ремонтопригодной, обязательно используйте макеты. Вы, а не общие заявления или культы груза, являетесь главным судьей того, что лучше для вашей системы в вашем контексте.

Answer 2

Вы никогда не издеваетесь над доменным объектом

Могут быть разные причины, чтобы избежать насмешек над объектами вашего домена:

1. Поддельные библиотеки, так же как и ORM, могут влиять на дизайн ваших доменных объектов. Они обычно требуют интерфейсов или виртуальных методов в C #.

2. Предпочтение при тестировании на реальных экземплярах. Очень часто люди используют насмешливые библиотеки, потому что это простой способ создать фальшивку или заглушку. Очень часто вы можете создать экземпляр вашего доменного объекта и использовать его в своем тесте. Скорее всего, тот факт, что метод Update был вызван, может быть легко проверен путем изменения состояния.

Обычно я высмеиваю объекты и просто проверяю, вызывается ли метод Update с правильными аргументами. Но теперь я должен проверить, правильно ли он вызывается, проверяя его поля и издеваясь над калькулятором, точно так же, как я это делал при модульном тестировании самого метода Update.

Как весело будет, когда метод Update немного изменится, и каждый из этих тестов внезапно прекратится и потребует рефакторинга ...

Уже упоминалось в комментарии, что , вероятно, Update метод имеет много обязанностей , и поэтому используется во многих случаях использования.

Есть разные вкусы, когда дело доходит до определения тестируемой системы (sut). Если вы склонны тестировать классы, то вы часто используете насмешливые библиотеки. Если вы склонны тестировать сценарии или поведение, то, скорее всего, вы будете заботиться только об изменениях состояния.

Вероятно, вы можете исследовать другой дизайн для вашего доменного объекта: попробуйте разделить метод Update на явные доменные методы, чтобы каждый клиент вызывал свое поведение. При таком подходе «достаточно длительный» тест для метода Update может даже устареть, поскольку он будет проверен другими тестами.

Answer 3

Вы никогда не издеваетесь над доменным объектом

Это скорее эвристика, чем лучшая практика.И я могу себе представить, что это имеет смысл в некоторых проектах.

Эта эвристика может помочь иметь лучшие тесты.Хорошие тесты легко написать, легко прочитать, и они сломаются, как только что-то пойдет не так.Если вы издеваетесь над моделью своего домена, вам, вероятно, также придется высмеивать ее поведение.И если у вас есть какое-то сложное поведение в вашей модели, насмешка будет занимать много времени.Тест также будет более хрупким (при прогнозировании выходных данных модели предметной области могут возникать ошибки).

Другой альтернативой является проведение общедоступного модульного тестирования.Это означает, что проверяемый модуль будет представлять собой не отдельный класс, а класс и некоторые его зависимости.Другими словами, вы просто используете конкретный объект вашей доменной модели в тесте.

Обычно я высмеиваю объекты и просто проверяю, вызывается ли метод Update с соответствующими аргументами.Но теперь я должен проверить, правильно ли он вызывается, проверяя его поля и издеваясь над калькулятором, точно так же, как я это делал при модульном тестировании самого метода Update.

Проверка того, что вызывается метод updateне обязательно означает успех теста.Это, вероятно, не то, что вы хотите проверить, чтобы убедиться, что ваш сервис работает правильно.Если вы пройдете конкретный класс вашей модели (включая калькуляторы), вам не придется делать никаких бесполезных проверок или повторять то, что было сделано в других тестах.

Одно из различий между этим решением и классами тестированияизолированно то, что при наличии ошибки в модели вашего домена многие другие тесты не пройдут.Но, на мой взгляд, это совершенно нормально, так как все равно придется исправить.