Автоматизированные тесты: насмешка против создания графа тестового объекта (с использованием контейнера IoC), что лучше при каких условиях?

Question

Как вы решаете, что выбрать:

1. использовать фиктивные объекты для теста ИЛИ
2. создать тестовый объект / граф объектов с использованием инфраструктуры IoC и запустить тест для этих данных

Answer 1

Это зависит от того, что вы пытаетесь проверить. Модульные тесты с отключенными соавторами великолепны, потому что

• Они действительно очень быстрые
• Они маленькие и простые для понимания
• Они не зависят от более широкого мира, что облегчает их запуск
• Они обеспечивают отличную локализацию дефектов

Однако чистые модульные тесты не могут сказать вам, правильно ли вы сконфигурировали ваши объекты в вашем контейнере IoC, работает ли строка подключения к базе данных и т. Д. Вам нужен тест, который запускает ваш контейнер IoC и действительно обращается к БД, чтобы доказать, эти вещи.

Если вы напишете как можно больше своих тестов как можно более чистых, автономных модульных тестов, ваша сборка останется быстрой. Это очень важно, так как медленный булид работает меньше. Тем не менее, не забудьте добавить несколько проводных тестов, чтобы доказать, что ваше приложение «держится вместе».

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

Вся партия затем включается в некоторые функциональные тесты уровня приложения, чтобы доказать, что само приложение выполняет то, что хочет пользователь.

Следует иметь в виду стоимость времени каждого типа теста. Переход от чистого модуля -> проводного -> функционального тестирования стоит порядка времени выполнения и сложности, когда они ломаются.

Answer 2

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

Если вы создаете тестовый объект / объект-граф, вам нужно настроить его , чтобы он предоставлял нужные вам данные. Это, вероятно, гораздо больше работы, чем вы хотите.

Для интеграционных тестов, конечно, вы должны тестировать целый граф объектов одновременно.

Answer 3

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

Для более проблемных внутренних подключений (в настоящее время - один вызов ESB) или функций, которые требуют сложного состояния, который я издеваюсь.

Answer 4

Если вам нужно написать много кода инициализации - фреймворк для фреймворка, вероятно, поможет вам писать лучше, проще для юнит-тестов.

Нет необходимости переписывать код, который может вас спасти.