Написание среды модульного тестирования для тестирования хранимых процедур SQL

Question

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

Answer 1

Уже есть одна среда тестирования для Sql Server - TSQLUnit . Может быть, вы можете получить некоторую полезную информацию от него.

Answer 2

Уже есть модульные тесты. Помимо dbUnit и sqlUnit попробуйте:

MyTAP: https://github.com/hepabolu/mytap
datacharmer.org: http://datacharmer.blogspot.com/2006/01/mysql-5-general-purpose-routine_27.html

Answer 3

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

Меня часто спрашивают, есть ли что-то подобное для MySQL. Может быть, вы уже что-то написали?

Answer 4

Попробуйте TST: http://tst.codeplex.com

Answer 5

В базе данных не должно быть достаточного количества логики, чтобы провести тестирование.

Answer 6

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

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

Answer 7

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

Моя мысль о том, чтобы просто протестировать DAL, заключается в том, что вы по сути тестируете сами хранимые процедуры с добавленным кодом .Net DB, и я не думаю, что нам нужно беспокоиться о модульном тестировании. Таким образом, вы можете использовать все инструменты и процессы, которые у вас уже есть, для модульного тестирования. Кажется, что нужно приложить немало усилий, чтобы разработать отдельную структуру для чего-то, что (IMHO) может быть одинаково хорошо выполнено с существующими инструментами.

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

Ура, V * +1007 *