Как выполнить модульное тестирование контроллера ядра .NET api с введенными зависимостями, которые также имеют зависимости с MOQ или Fake? - PullRequest
0 голосов
/ 19 февраля 2019

Я реализовал контроллер API, который будет использоваться частью другой системы, а не пользователями напрямую.Тем не менее, я хочу предоставить для этого модульный тест.Я начал смотреть на MOQ, а потом понял, что мой конкретный случай немного сложнее.Код работает, но, как я уже сказал, я пытаюсь сделать для него тест, без (в идеале) записи каких-либо данных в БД.

Структура классов выглядит следующим образом

api controller
    |__MyCustomClass (injected via startup along with configuration)
            |__UtilityClass (method: ImportSomeDataFromaFolder)
                |__MydataRepositoryClass
                    |__CustomDerivedDbContext
                        (override savechanges etc so as to capture EF errors)

Примечание:- Возвращаемое значение метода api представляет собой сложный объект JSON.- Я хотел бы иметь тест, который позволяет избежать записи в БД- Я создаю собственный DbContext (CustomDerivedContext) и переопределяю изменения сохранения, чтобы захватывать объекты EF, которые изменяются в списке, например.List<EntityEntry>- Метод ImportSomeDataFromaFolder, после анализа данных в объектах POCO и отправки их в репозиторий для сохранения в Db, затем перемещает файл в другую папку.При тестировании я бы предпочел, чтобы этого не произошло, а просто загрузил файл для разбора.

  • Есть 3 основных вещи для тестирования:(1) Загружаются ли данные в файле в объекты POCO?(2) Правильно ли переведены объекты POCO в объекты модели EF?(3) Возвращает ли API-интерфейс объект JSON, который содержит ожидаемые результаты

Или я делаю вещи более сложными, чем то, что должно быть сделано для модульного теста.Я хочу написать тест для контроллера api, но это CustomDerivedDbContext, который, кажется, я хочу использовать здесь подделку, так как тогда я мог бы удалить шаг, который фактически вызывает базовые сохранения DbContext.

1 Ответ

0 голосов
/ 19 февраля 2019

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

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

Если юнит тестирует контроллер API, то в идеале все, что вам нужно, это макет явно введенных абстракций.

Контроллеру API не нужно ничего знать о зависимостях его зависимостей, если соблюдается правильное разделение интересов.

...