Какие лучшие практики вы используете для тестирования запросов к базе данных? - PullRequest
8 голосов
/ 04 ноября 2008

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

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

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

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

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

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

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

Ответы [ 9 ]

3 голосов
/ 04 ноября 2008

Вот несколько рекомендаций:

  1. Использовать изолированную базу данных для модульного тестирования (например, никаких других тестовых прогонов или действий)
  2. Всегда вставляйте все тестовые данные, которые вы собираетесь запрашивать, в одном и том же тесте
  3. Напишите тесты для случайного создания разных объемов данных, например, случайное количество вставок, скажем, от 1 до 10 строк
  4. рандомизировать данные, например для логического поля случайная вставка и true или false
  5. Вести подсчет в тесте переменных (например, количество строк, количество истин)
  6. Для Asserts выполнить запрос и сравнить с локальными тестовыми переменными
  7. Использование транзакций служб предприятия для отката базы данных до предыдущего состояния

См. Ссылку ниже для техники транзакции услуг предприятия:

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

3 голосов
/ 04 ноября 2008

Тестирование хранимых процедур требует, чтобы у каждого тестируемого был отдельный экземпляр БД. Это требование. Если вы делитесь средами, вы не сможете положиться на результаты своего теста. Они будут бесполезны.

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

Есть несколько инструментов, которые помогут вам в этом. DbUnit является одним из них, и я также считаю, что у Microsoft был инструмент Visual Studio для специалистов по базам данных, который содержал некоторую поддержку для тестирования БД.

1 голос
/ 05 ноября 2008

В SQLServerCentral есть статья здесь (возможно, вам придется зарегистрироваться, но она бесплатна и без строк) об инфраструктуре модульного тестирования TSQL, называемой tsqlUnit. Это открытый исходный код, который следует традициям платформы xUnit.

Следует шаблону SEAT TDD:

Настройка - подготовить условия теста, манипулируя объектами, таблицами и / или данными

Упражнение - вызвать производственный код

Утверждение - проверьте, что фактический результат равен ожидаемому результату

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

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

Фреймворк можно скачать здесь .

1 голос
/ 04 ноября 2008

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

Люди Django предлагают подкласс стандартного класса Python unittest TestCase, который заполняет базу данных известным фиксатором - известным набором строк данных.

В случае с Django (и Python) заполнить базу данных проще всего из извлечения данных JSON. Другие форматы файлов для фикстуры могут использоваться для других платформ. Например, если вы работаете в Oracle, вам может быть проще работать с CSV-файлами.

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

Кроме того, тестер Django создает временную схему для целей тестирования. Это легко для Django, потому что они имеют полный компонент объектно-реляционного управления, который включает создание DDL. Если у вас этого нет, вам все равно понадобится сценарий DDL, чтобы вы могли создавать и утилизировать тестовую схему для целей юнит-теста.

1 голос
/ 04 ноября 2008

У нас есть пустая база данных для каждого разработчика и тестировщика.

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

Затем мы можем протестировать несколько разных сценариев на одной и той же БД (один за другим), и мы никогда не помечаем пальцы других тестеров.

Это касается тестирования самого доступа к данным. Для тестирования сервиса мы делаем почти то же самое, но мы тестируем только внутреннюю часть сервиса - мы на самом деле не обращаемся к сервису, мы создаем экземпляр класса обработки сервиса и передаем все, что нам нужно. Таким образом, мы тестируем код, а не инфраструктуру (сообщение и т. Д.)

1 голос
/ 04 ноября 2008

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

1 голос
/ 04 ноября 2008

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

Эти вызовы рассчитаны на то, чтобы:

1 / Они не занимают много времени.

2 / Они не сильно отличаются (плохим образом) от предыдущей ночи.

Таким образом мы быстро отлавливаем ошибочные запросы или изменения БД.

0 голосов
/ 01 августа 2018

Это сложная настройка, но я рекомендую контейнеры TDDing.

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

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

ThoughtWorks

0 голосов
/ 04 ноября 2008

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

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

...