Почему бы не поразить базу данных внутри юнит-тестов?

Question

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

Я хотел бы знать, насколько эффективно это руководство по модульным тестам. Я видел концепцию «интеграционных тестов», но я не уверен, какие инструменты использовать для интеграционных тестов. Например, можно ли создать интеграционный тест с использованием тестового фреймворка, такого как Nunit?

Спасибо

Hugo

Answer 1

Вы просто находитесь в семантической серой области.

• Системные тесты охватывают всю систему от начала до конца.
• Модульные тесты могут использоваться для описания подсегмента сквозного цикла.

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

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

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

Затем напишите серию модульных тестов, которые тестируют прикладной уровень (включая уровень данных) ...

И, наконец, напишите несколько системных тестов на основе браузера ...

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

Но иногда (как я на самом деле сейчас делаю, когда пишу это) вы ДОЛЖНЫ изучить базу данных, чтобы создать значимый и надежный набор тестов (я тестирую протоколы передачи с сервера на сервер).

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

Answer 2

Существует две основные причины, по которым модульные тесты не попадают в базу данных:

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

В вашем случае вам нужно проверить хранимые процедуры. Затем вам нужно написать тест, который запускает эти хранимые процедуры. Либо вы можете запустить их через свой код (интеграционный тест), либо вы можете запустить их непосредственно из теста (что-то вроде модульного теста). В обоих случаях вы можете использовать Nunit.

Answer 3

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

Это также то, почему вы не должны иметь большой вес в чистом, теоретически осмысленном TDD, U нит T эссетах. Хотя юнит-тестирование само по себе неплохо, и на самом деле это очень важно для обеспечения правильной сборки каждым компонентом программистами - системное тестирование гораздо важнее. В целом, может быть сложнее найти точный метод, который вызвал сбой системных тестов, они более реалистичны и фактически тестируют систему .
Мне кажется хорошим компромиссом так называемое «тестирование компонентов», которое больше похоже на системное тестирование, но только для одной небольшой части системы, сквозной, - на мой взгляд.

(Теперь опровергните опровержения TDD ... :))

Answer 4

YMHO Здесь есть немного семантической проблемы и немного технической проблемы.

Предполагается, что модульный тест проверяет небольшую часть кода изолированно, чтобы проверить его без другого кода. Неудачный модульный тест должен подразумевать, что только небольшая часть кода должна быть проверена исправлена ​​(как правило, код, реализующий функциональность, и сам модульный тест).

Существуют другие области тестирования для проверки работоспособности системы в целом (системный тест) или функциональные тесты для проверки полных функций или интеграционные тесты для проверки взаимодействий, регрессионное тестирование для проверки отсутствия уже исправленного теста и т. Д.

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

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

Answer 5

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

Преимущества тестирования с базой данных:

• Тестирование более реалистично (с использованием реальной базы данных)
• Меньше тестируемого кода для написания (не нужно писать макет базы данных)

Недостатки тестирования с базой данных:

• Ваши тесты не могут быть запущены, пока не будет написан слой доступа к базе данных
• Если есть ошибка или тестовый сбой, вы не знаете, есть ли ошибка в вашем коде или на уровне доступа к базе данных

Недостатки особенно важны, если (но, возможно, только если) человек, пишущий верхний уровень, не совпадает с человеком, пишущим слой доступа к базе данных.

Answer 6

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

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

Answer 7

Проблема при обращении к базе данных в ваших тестах заключается в том, что изменение базы данных или вашего кода может не пройти тест. Модульный тест обычно должен указывать как можно более прямое изменение, которое заставило его потерпеть неудачу. Так что если вы хотите проверить код для доступа к БД, возможно, используйте фиксированную тестовую базу данных. Таким образом, вы уверены, что код, который обращается к БД, неверен, потому что вы знаете, что база данных не изменилась, и если вы хотите изменить настройку БД, сначала измените тестовую БД и увидите, что ваш тест не пройден, затем исправьте его, а затем измените не тестовая БД. В проекте, в котором я работал, мы создали небольшую базу данных, которая генерировалась в памяти перед каждым тестом.