Модульное тестирование методологии базы данных

Question

Я собираюсь написать модульные тесты для нового веб-приложения.

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

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

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

Answer 1

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

---

A Модульный тест должен проверять только один блок. Он не должен полагаться на внешние зависимости, такие как базы данных, веб-службы или файловые системы. Вместо этого эти зависимости должны быть смоделированы, чтобы можно было точно контролировать состояние каждого отдельного теста.

A Модульный тест должен быть атомарным, последовательным и повторяемым. Как указывает Джон, тест должен быть в состоянии запускаться сам по себе или в наборе с одинаковым поведением каждый раз.

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

---

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

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

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

Лучший совет, который я могу вам дать, - это начать читать Приемочное тестирование и Разработка на основе поведения .

Некоторые люди, которые могут помочь:

Гойко Адзич , Боб Мартин

Некоторые инструменты, которые могут помочь:

FitNesse , SpecFlow , Огурец

Пожалуйста! Пожалуйста! Пожалуйста! Читайте и учитесь у этих ребят и тех сообществ. Они направят вас в правильном направлении и помогут избежать долговременных проблем с автоматическим тестированием.

Answer 2

Юнит-тесты не должны зависеть от их порядка и не должны зависеть от состояния того, что тестируется. Они должны настроить все необходимое состояние.

То, что вы описали, может быть полезным тестом, но это не набор юнит-тестов.