Какой смысл тестировать поддельные репозитории?

Question

Я пытался подтолкнуть свой менталитет при разработке дома к тому, чтобы он был больше ориентирован на TDD и немного DDD.

Однако я не понимаю одной вещи: зачем вам создавать поддельный репозиторий для тестирования?Я на самом деле не очень разбирался в этом, но, безусловно, идея тестирования заключается в том, чтобы помочь отделить ваш код (придавая вам больше гибкости), урезать необходимый код и снизить количество ошибок.

Так может ли кто-нибудь просветить мои глупые мозги относительно того, почему некоторым нравится тестировать поддельные репозитории?Я бы подумал, что тестирование на реальной базе данных - гораздо лучшая альтернатива созданию поддельной, потому что тогда вы ЗНАЕТЕ, что это работает против вашего реального хранилища данных.

Answer 1

Поддельный репозиторий позволяет вам тестировать только код вашего приложения.

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

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

Поддельный репозиторий НЕ является заменой системному тестированию, которое будет включать вашу базу данных.

Answer 2

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

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

Единственный недостаток очевиден:

• Как вы можете быть уверены, что это действительно работает?

... и это то , что интеграционные тесты предназначены для.

Answer 3

Я поддержал ответ Giraffe, но хочу добавить всего пару моментов:

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

• С помощью местных макет/поддельные репозитории усиливает пользователю сведения слой абстракции, который хорош практика дизайна.

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