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