Когда имитировать доступ к базе данных

Что я делал много раз при тестировании вызовов базы данных, так это настраивал базу данных, открывал транзакцию и откатывал ее в конце. Я даже использовал базу данных sqlite в памяти, которую я создаю и уничтожаю вокруг каждого теста. И это работает и относительно быстро.

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


person Emil Ivanov    schedule 04.08.2011    source источник


Ответы (2)


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

Целью модульного теста является тестирование наименьшего тестируемого фрагмента кода без участия другой логики приложения. Этого нельзя достичь при использовании вашей техники ИМО.

Сделать код пригодным для тестирования путем абстрагирования слоя данных — хорошая практика. Это сделает ваш код более надежным и простым в обслуживании. Если вы реализуете шаблон репозитория, имитировать вызовы вашей базы данных довольно просто.

Кроме того, модульные и интеграционные тесты служат разным потребностям. Модульные тесты должны доказать, что часть кода технически работает, и отловить краеугольные случаи. Интеграционные тесты проверяют интерфейсы между компонентами на соответствие дизайну программного обеспечения. Сами по себе модульные тесты не могут проверить функциональность части программного обеспечения.

ХТН

person Stephane    schedule 04.08.2011

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

Однако я предполагаю, что выполнение каждого из ваших тестов через каждый уровень вашей системы делает разработку через тестирование очень сложной. Необходимость наличия каждого слоя и работы для того, чтобы тест прошел, в значительной степени исключает необходимость тратить несколько минут на написание теста, несколько минут на его прохождение и повторение. Это означает, что ваши тесты не могут подсказать, как ведут себя и взаимодействуют отдельные компоненты; например, ваши тесты не заставят вас делать вещи слабосвязанными. Кроме того, скажем, вы добавляете новую функцию, а в другом месте что-то ломается; Детальные тесты, которые выполняются для компонентов изолированно, значительно упрощают отслеживание того, что пошло не так.

По этим причинам я бы сказал, что стоит «двойную работу» по созданию и поддержке как интеграционных, так и модульных тестов, с высмеиванием или заглушкой вашего DAL в последнем.

person Steve Wilkes    schedule 04.08.2011