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

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

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

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


repository tdd fake-repositories
person John_    schedule 02.01.2009    source источник
comment
Я тоже не вижу причин, достаточно просто настроить экземпляр базы данных и использовать его для разработки.   -  person Otávio Décio    schedule 02.01.2009
comment
Вы спрашиваете как о тестировании поддельных репозиториев, так и о тестировании против поддельных репозиториев. Я думаю, вы имеете в виду против, но не могли бы вы прояснить вопрос, чтобы люди могли дать более целенаправленные ответы?   -  person Blair Conrad    schedule 02.01.2009

Ответы (3)


arrow_upward
21
arrow_downward

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

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

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

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

person Giraffe    schedule 02.01.2009
comment
Значит, создание поддельного репозитория для добавления и обновления элементов для прохождения тестов бессмысленно? Его следует использовать только для тестирования кода вашего приложения? Если это правильно, я обновлю это принятым ответом. - person John_; 02.01.2009

arrow_upward
7
arrow_downward

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

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

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

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

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

person Spoike    schedule 02.01.2009

arrow_upward
2
arrow_downward

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

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

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

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

person joel.neely    schedule 02.01.2009