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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Я проголосовал за ответ Жирафа, но хочу добавить только пару пунктов:

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

• Использование локального репозитория фиктивного / фальшивого усиливает пользователя данных слой абстракции, который хорош практика проектирования.

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