Как выполнить тестирование базы данных?

Question

Я слышал, что при разработке приложения, которое использует базу данных, вы должны выполнить тестирование модуля базы данных.Каковы лучшие практики в модульном тестировании базы данных?Каковы основные проблемы при выполнении модульного тестирования БД и как сделать это «правильно»?

Answer 1

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

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

Каковы основные проблемы при выполнении модульного тестирования БД

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

и как это сделать "правильно"?

Как уже было сказано, следуйте известным рекомендациям и используйте специальные инструменты / платформы:

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

Answer 2

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

• Каждому тестеру нужна отдельная база данных, чтобы не мешать деятельности другого тестера / разработчика
• Чтобы иметь простой способ создания базы данных для тестирования (это связано с наличием базы данных SQL Server под контролем версий). Это особенно полезно при попытке найти, что пошло не так, если некоторые тесты не пройдены
• Сосредоточьтесь на определенных областях и создавая тесты для одного модуля, вместо того, чтобы охватывать все сразу. Детальное добавление тестов - это хороший способ повысить эффективность
• Обязательно предоставьте как можно больше подробностей при сбое теста, чтобы упростить отладку
• Использовать одни и те же данные испытаний для всех испытаний

Если тестирование выполняется с использованием инфраструктуры tSQLt, процесс модульного тестирования может быть сложным при работе с большим количеством баз данных из нескольких экземпляров SQL Server. Чтобы поддерживать, выполнять и управлять модульными тестами непосредственно из SQL Server Management Studio, ApexSQL Unit Test может использоваться в качестве решения

Answer 3

Взгляните на эту ссылку . В нем рассматриваются некоторые основы создания модульного тестирования хранимых процедур в SQL Server, а также различные типы модульных тестов и время их использования. Я не уверен, какую СУБД вы используете, но, очевидно, эта статья ориентирована на SQL Server.

Украдено из артикула:

Функциональные испытания

Первый и, вероятно, наиболее распространенный класс модульного теста базы данных является функциональный тест. На мой взгляд, особенность тесты тестируют основные функции или API, если хотите - вашей базы данных из точка зрения потребителя базы данных. Тестирование программируемости базы данных объекты является основным сценарием здесь. Итак, тестируя все хранимые процедуры, функции и триггеры внутри вашего базы данных представляют собой функциональные тесты в по моему мнению. Чтобы проверить хранимую процедуру, вы бы выполнили хранимую процедуру и убедитесь, что либо ожидаемый результаты были возвращены или соответствующее поведение произошло. Тем не менее, вы можете проверить больше, чем просто эти типы объектов. Вы можете представьте себе, что вы хотите, чтобы представление, например, вернуть соответствующий расчет из вычисляемого столбца. Как вы можете видеть, возможности в этом царство велико.

Испытания схемы

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

Тесты безопасности

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

Тестирование данных запаса

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

Answer 4

Я рад, что вы спросили о модульном тестировании, а не о тестировании вообще.

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

• Типы данных / Размер / Наборы символов (попробуйте вставить шведское имя, длинные URL-адреса или числа из реальных миров и посмотрите, в порядке ли ваши определения столбцов)
• Триггеры
• Ограничения (внешние ключи, уникальность ...)
• Просмотры (проверьте, что данные правильно включены / исключены / преобразованы)
• Хранимые процедуры
• UDFs
• Права доступа
• ...

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

Как правило, интеграционное тестирование завершено. Это означает, что создан Test Suite на языке программирования, таком как PHP или Java, и тесты выдают несколько запросов. Но если что-то не получается или есть некоторые исключения, понять проблему сложнее по двум причинам:

• Проблема может быть в вашем коде PHP, или в конфигурации PHP, или в сети, или ...
• Операторы SQL труднее читать и изменять, если они встроены в другой язык программирования.

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

• СТК / Единица http://stk.wikidot.com/stk-unit
• utMySQL http://utmysql.sourceforge.net/

Answer 5

Я использую junit / nunit / etc и кодирую модульные тесты базы данных с помощью java или c #. Затем они могут выполняться на сервере интеграции, возможно, с использованием отдельной схемы для тестовой базы данных.

Последний разработчик oracle sql поставляется со встроенной структурой модульного тестирования. Я посмотрел на это, но НЕ использовал бы это. Он использует графический интерфейс для создания и запуска тестов и сохраняет все тесты в базе данных, поэтому не так просто поставить тестовые случаи под контроль версий. Вероятно, есть и другие тестовые среды, которые, я думаю, могут быть специфичны для вашей базы данных.

Хорошая практика похожа на обычные юнит-тесты:

• поставить тесты под контроль источника
• делать тесты, которые работают быстро - не тестируйте слишком много за один раз
• сделайте ваши тесты воспроизводимая

Answer 6

Взгляните на структуру DBTestDriven. Это прекрасно работает для нас. Загрузите его с GitHub или с их сайта.

Answer 7

Что касается разработки JVM, модульные тесты могут извлечь выгоду из абстракции JDBC: как только вы узнаете, какие данные JDBC получены при доступе к БД, эти данные JDBC могут быть «воспроизведены».

Таким образом, случай доступа к БД можетбыть «воспроизведенным» для тестирования без целевой БД: нет сложности с тестированием / изоляцией данных, упростите непрерывную интеграцию.

Мой фреймворк Acolyte - полезный фреймворк в этом смысле (включая инструмент Studio GUI для «записи» результата БД): https://github.com/cchantep/acolyte