Репозиторий Mock против реального репозитория с Mocked Data

Question

Я, должно быть, делаю что-то в корне неправильно.

Я внедряю свои репозитории, а затем проверяю их с помощью фиктивных данных. Все хорошо.

Теперь я хочу протестировать свои доменные объекты, поэтому я указываю их на фиктивные репозитории.

Но я обнаружил, что мне нужно повторно внедрить логику из «реальных» репозиториев в макеты или создать «вспомогательные классы», которые инкапсулируют логику и взаимодействуют с репозиториями (реальными или фиктивными), а затем Я должен проверить те тоже.

Так что же мне не хватает - зачем внедрять и тестировать фиктивные репозитории, когда я могу использовать реальные с фиктивными данными?

РЕДАКТИРОВАТЬ: Чтобы уточнить, «по поддельным данным» я не попал в фактическую базу данных. У меня есть «слой макета БД», который я могу вставить в реальные репозитории, которые возвращают известные данные.

Answer 1

Может быть, вы смешиваете свои абстракции. возможно, некоторые из помощников и логики, о которых вы говорите, должны быть в ваших объектах домена. В ваших репозиториях должен быть реализован интерфейс CRUD. Таким образом, логика вашего домена должна использовать 8 действий из хранилища. Хорошее извлечение и Плохое извлечение (исключение выброшено) - только два из восьми. Один из тестов - как обрабатывается Bad в объекте домена. Остальные тесты должны проверять исправность.

Answer 2

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

Теперь представьте, что вы создали модуль доступа к базе данных. Модуль, кажется, работает нормально. Затем вы делаете читателя конфигурации, который читает из базы данных. Вместо тестового модульного модуля модуля доступа к базе данных вы используете свой реальный модуль базы данных поверх фиктивных данных конфигурации в тестовом модуле базы данных. Кажется, все еще работает нормально. Теперь вы добавляете слой графического интерфейса, который использует объект конфигурации, возвращаемый модулем чтения конфигурации. Вместо того, чтобы издеваться над «вареными» данными конфигурации, вы используете реальный модуль, который, очевидно, работает. И теперь ваш графический интерфейс перестает работать на определенное значение. Где ошибка? В графическом интерфейсе, в программе чтения конфигурации, в средствах доступа к базе данных или в значениях в фиктивной базе данных?

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

Answer 3

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

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