Как я должен тестировать методы с большим количеством DOC (зависимый от кода)?

Question

Допустим, у нас есть метод, который в основном объединяет различные другие методы;не делает большую часть своей собственной логики.Скажем, это типичный член класса обслуживания на уровне сервиса, вызов методов в классах модели домена (бизнес), классы доступа к данным и класс утилиты / сервиса электронной почты.

Я считаю, что написаниеНастоящий модульный тест для этого метода требует большого количества двойных настроек теста, и здесь очень мало логики.Это кажется , как будто стоимость перевесит значение, если я продолжу в том же духе.Что мне делать?

Answer 1

Вы не должны иметь более одного макета на юнит-тест.От Искусство юнит-тестирования Роя Ошерова (стр. 94):

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

Здесь - это связанный вопрос переполнения стекаэто может помочь.

Answer 2

Я не пурист, когда дело доходит до юнит-тестов. Существует точка снижения доходности, когда затраты на создание и поддержку данного теста, очевидно, превышают выгоду, которую вы получите от выполнения этого теста. Однако не существует жесткого и быстрого правила относительно того, где эта точка существует.

Я решил написать модульные тесты для кода, подобного тому, что вы описали. Однако в большинстве этих случаев я убедился, что базовые объекты (над которыми вы будете насмехаться) имеют соответствующие модульные тесты, запущенные против них. Однако в тех случаях, когда существует значительный объем внутренней логики, модульное тестирование по-прежнему является определенным порядком дня.

Я не думаю, что есть правильный ответ на этот вопрос, но, надеюсь, мои комментарии ниже помогут вашему мыслительному процессу о том, как и нужно ли вам это тестировать.