Когда имитировать доступ к базе данных - PullRequest
5 голосов
/ 04 августа 2011

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

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

Ответы [ 2 ]

7 голосов
/ 04 августа 2011

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

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

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

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

НТН

3 голосов
/ 04 августа 2011

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

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

...