Я реализовал контроллер 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.