Лучшая практика тестирования SQL - PullRequest
2 голосов
/ 08 мая 2009

Какова лучшая практика для тестирования SQL (хранимые процедуры, представления, запросы, триггеры ...), за исключением автоматического тестирования? В большинстве случаев запрос работает или возвращает тысячи строк, поэтому их немного сложно проверить. Я хочу знать, как вы обычно проводите тестирование SQL-запроса. Можете ли вы указать мне хороший (онлайн) справочник?

Ответы [ 2 ]

3 голосов
/ 08 мая 2009

Попробуйте исключить лишние переменные.

Способы сделать это:

  • Каждый тест должен проверять только одну функцию (представление, хранимую процедуру и т. Д.)
  • Использовать известные тестовые данные (они должны быть из реальной среды (но не из реальной среды)
  • Используйте наименьшее количество тестовых данных, которые адекватно тестируют функцию.
1 голос
/ 08 мая 2009

Для вставок, обновлений, удалений Я проверяю состояние таблицы до и после запуска proc для записей, которые соответствуют условиям вставки обновления или удаления. Поэтому, если я добавляю 7 записей, они не должны быть в таблице заранее и должны быть там после.

Выбор с тысячами записей может быть сложнее. Нет никакой альтернативы фактическому знанию ваших данных и того, что вы ожидаете получить. Например, я знаю, что у определенного клиента есть около 2000 торговых представителей. Если я запускаю запрос, в котором должны быть все повторы, а их всего около 1000, я знаю, что что-то не так. Иногда я помещаю результаты запроса во временную таблицу, чтобы можно было вести статистику по ней. Если я делаю отчет о посетителях, я могу видеть, что в отчете за отчетный период есть 200 отдельных встреч в соответствии с моим запросом. Если я смотрю только на эту таблицу и вижу, что за один и тот же период времени проводится 350 собраний, я смотрю, что исключает собрания, и обычно смотрю детали одного или нескольких исключенных собраний и связанных с ними таблиц, чтобы понять, почему не появляется Обычно вы найдете статус, который необходимо учитывать, или какие-то неверные данные.

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

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

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

Триггеры, которые я тестирую, сначала записывая их как обычные запросы (после первого создания и заполнения временных таблиц для #inserted и #deleted). Я добавляю несколько записей в мои временные таблицы, потому что каждый триггер должен правильно обрабатывать вставки / обновления или удаления нескольких записей. Затем я пишу код для отображения состояния before и after и помещаю все это в транзакцию, чтобы можно было откатить ее во время тестирования.

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