Сегодня у меня возникла идея написать единую тестовую структуру для хранимых процедур в MySQL. Полная идея написана на недавнем посте в моем блоге. Короче говоря, это выглядит так: Я хочу автоматизировать мое тестирование процедур, я хочу использовать стандартизованный способ проверки моих процедур. Модульное тестирование широко документировано, и там есть ракеты XUnit zillion, почему бы не написать их для MySQL (или любой другой базы данных). Разумеется, это был бы открытый источник. Как вы думаете? Это глупо, глупо, бесполезно или что? Или другая идея - написать общую базу данных в SQL. Хм, я действительно хочу обсудить это с кем-то, собрать мысли и идеи.
Написание модульной системы тестирования для тестирования хранимых процедур SQL
Ответ 1
Уже существует одна среда тестирования для Sql Server - TSQLUnit. Возможно, вы сможете получить от него полезную информацию.
Ответ 2
Да, отличная идея. У меня был небольшой успех: pgTAP. Я использовал его в нескольких проектах, как для тестовой разработки баз данных, так и для написания тестов для существующих процедур, чтобы иметь возможность эффективно реорганизовать их.
Меня часто спрашивали, есть ли что-то подобное для MySQL. Может быть, вы уже что-то написали?
Ответ 3
Там уже проводятся тесты. Помимо dbUnit и sqlUnit, попробуйте:
MyTAP: https://github.com/hepabolu/mytap
datacharmer.org: http://datacharmer.blogspot.com/2006/01/mysql-5-general-purpose-routine_27.html
Ответ 4
Я склонен к unit test уровню доступа к данным, это всегда боль в заднице, потому что вам нужно настроить правильную базу данных с соответствующими данными. Существуют генераторы данных, которые могут помочь (например, генератор данных RedGate) упростить процесс настройки.
Мое мышление только для проверки DAL заключается в том, что вы, по сути, сами тестируете сами хранимые процедуры с добавленным кодом .Net DB, который, как мне кажется, нам не нужно беспокоиться об модульном тестировании. Таким образом, вы можете использовать все инструменты и процессы, которые у вас уже есть для модульного тестирования. Представляется, что нужно много усилий разработать отдельную структуру для чего-то, что может (ИМХО) быть одинаково хорошо совместимо с существующими инструментами.
У меня есть открытый ум. Если есть льготы, которые я пропускаю, пожалуйста, скажите мне.
Cheers, В
Ответ 5
Одним из преимуществ было бы то, что тест будет написан в том же окружении хранимых процедур, написанных и выполненных, которые будут поддерживаться специализированным разработчиком баз данных за пределами основного приложения. Разработчику приложения не нужно быть мастером программирования реляционной базы данных или разработчиком базы данных для освоения современного языка разработки приложений. У вас теперь есть тест на все. Почему бы им не использовать их для базы данных, написанной sql и выполняемой вне любого встроенного приложения.
Если вы разрабатываете многоуровневое приложение, имеет смысл разделить каждую часть и протестировать ее отдельно.
Ответ 6
Попробуйте TST: http://tst.codeplex.com
Ответ 7
В базе данных не должно быть достаточной логики, чтобы сделать тестирование стоящим.