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

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

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

Спасибо

Уго

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Кроме того, почему вы не должны обладать большим весом в чистом, TDD-концептуальном, теоретическом святом U nit T ests. Хотя unittesting - это не плохая вещь сама по себе, и на самом деле очень важно, чтобы программисты правильно составляли каждый компонент - более важным является системное тестирование. В целом, может быть сложнее найти точный метод, который привел к сбою системных тестов, они более реалистичны и фактически тестируют систему.
Так называемое "тестирование компонентов", которое больше похоже на тестирование системы, но только для одной маленькой части системы, от конца до конца, кажется мне хорошим компромиссом.

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

Ответ 4

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

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

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

Недостатки тестирования с помощью базы данных:

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

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

Ответ 5

YMHO Существует немного семантической проблемы и немного технической проблемы.

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

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

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

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

Ответ 6

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

Ответ 7

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

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