Модульное тестирование - проблемы с динамическими / взаимосвязанными репозиториями

Question

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

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

Это работает довольно хорошо, но я сталкиваюсь с некоторыми проблемами:

• Когда сущности в одной поддельной коллекции ссылаются на сущности в другой поддельной коллекции, код в конструкторе хранилища взрывается и становится трудно управлять

• Когда модульный тест вызывает действие, которое изменяет поддельные данные хранилища, статический сборник изменяет состояние, делая практически невозможным работу с теми же данными в других модульных тестах

Итак, у меня есть два вопроса, которые могут потребовать от вас также объяснить ваш общий подход:

1. Как вы собираетесь настроить поддельную коллекцию для сущности, которая ссылается на другие поддельные коллекции / сущности?

2. Поддерживают ли ваши поддельные репозитории операции обновления / вставки / удаления? Если да, то как предотвратить изменения одного модульного теста на другой модульный тест?

Answer 1

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

• Насекомые Rhino
• Заменитель
• Moq

Answer 2

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

(Это атрибуты, специфичные для NUnit, поэтому я не могу комментировать, если другие платформы имеют аналогичные функции).