Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

Протестировать SQL-процедуры

594  
Murr патриот03.10.10 12:59
Murr
NEW 03.10.10 12:59 
И вот задмался Я над вопросиком...
Дано: База MSSQL2005 (с потенциальной миграцией на 2008, 2010 и етц...)
Интерфейс к базе - через вызовы процедур - по одной на каждую операцию
- Select, Update, Delete, Insert (SUDI).
Писаться это будет наполовину руками, наполовину автоматом. Понятно, что
будут ошибки. Так что есть желание протестить результат написания.
Есть ли какой-нибудь метод или тоолс для этого?
В смысле - простой скрипт для тестирования Я написал, но он требет чела с
глазами и руками чтобы провести тестирование. Интересует - полный автомат
- раз зарядил - получил список непрошедших тесты.
#1 
  digital.pilot патриот03.10.10 17:30
digital.pilot
NEW 03.10.10 17:30 
в ответ Murr 03.10.10 12:59
раздать параметрам значения по умолчанию и вызывать в цикле по одной. Или даже лучше пачками по 4, наверно, чтоб передавать по цепочке ID объекта, который создается-селектится-апдейтится-удаляется.
#2 
  femidav свой человек03.10.10 17:35
Murr патриот03.10.10 20:07
Murr
NEW 03.10.10 20:07 
в ответ digital.pilot 03.10.10 17:30
Или даже лучше пачками по 4
-----
Примерно так и сделал. Вызывается 1-3+ процедуры. Но не получается полностью автоматизировать процесс.
#4 
Murr патриот03.10.10 20:55
Murr
NEW 03.10.10 20:55 
в ответ femidav 03.10.10 17:35
Читаю.
Рекомендаций вижу две - DbUnit и MOSK. Еще упоминается DJango. PHPUnit - пока не рассматриваем.
Начнем с MOSK.
Может быть и хорошо, но тестировать мне надо актуальные имплементации процедур. Подмена эмулятором вроде как не получится. Точнее - ее бы хватило, если бы тестировались бизнес-объекты. Но интересуют именно скл-процедуры.
Теперь DbUnit.
Пока не пробовал. Надо смотреть. Чего пока не вижу - на каком уровне сохраняется состояние базы. Сбросить таблицы в ноль Я могу и без этого - скрипты оформлены в виде пакетов - можно полностью заменить все что связано с таблицей не беспокоя остальное хозяйство.
Кто-то пользует? Как оно в работе? Многосхемное тестирование пока не интересует - проверить бы то что есть...
DJango.
Доступна какая-то бетта. Обычно бетта продукт стараюсь не использовать.
Если кто пробовал - поделитесь впечатлениями, плс.
Ну и уточню немного задачку.
Требуется протестировать процедуры. Возможно, что потребуется несколько последовательных тестов. После тестов база должна остаться в том же состоянии, что и до начала тестирования. Бэкап и ресторе - нежелателены - это другой инструментарий.
Желательно так же, чтобы все было по возможности простым и достаточно эффективным.
#5 
Nucleas прохожий06.10.10 00:11
06.10.10 00:11 
в ответ Murr 03.10.10 20:55
Требуется протестировать процедуры - означает выписать все бизнес правила и написать юнит тест на каждое правило.
Сохранить базу данных в неизменном виде - означает, что каждый юнит тест должен начинаться открытием тразакции и заканчиваться отменной транзакции.
Пример допустим сторед процедура делает суммирование столбца данных из некоторой таблицы. В рамках одной транзакции выполняем процедуру сохраняя результат до круда данных, делаем круд новых данных, выполняем процедуру, проверяем, что поведение сторед процедуры совпадает с ожидаемым и отменяем транзакцию.
Выбор как обращаться к данным зависит от технологии которую вы используете, например, возможно использование LinqToSql с провайдером к Вашей базе и NUnit для случая C#.
#6 
Murr патриот06.10.10 01:06
Murr
NEW 06.10.10 01:06 
в ответ Nucleas 06.10.10 00:11
каждый юнит тест должен начинаться открытием тразакции
------
Остается открытым вопрос - как сделать открытие транзакции при условии что интерфейс разрешает исключительно вызов процедур? Плюс - процедуры сами рулят внутренними транзакциями, которых там может быть не мало...
допустим
------
Можно. Нарушив требование по интерфейсу. Кроме этого, количество писанины и сопровождения станет точно неподъемным. Вопрос об отдельном тестировании процедур потому и возникает, что есть желание не делать лишнюю работу, а делать именно то, что нужно для тестов и получения результата.
NUnit для случая C#.
------
NUnit и так используется. Да, можно косвенно протестировать и процедуры. Но это - косвенно, не прямой юнит-тест. И он скажет очень относительно где именно есть проблема.
Прямо сейчас есть написанный класс, который Я плохо представляяю как именно тестировать. Если точнее - нужна декомпозиция класса, которая сильно не желательна - класс как раз и порожден желанием убрать избыточные сущности... и самое плохое - именно через него идет коммуникация с процедурами.
#7 
Nucleas прохожий06.10.10 01:20
NEW 06.10.10 01:20 
в ответ Murr 06.10.10 01:06
Это желательно внимательно прочитать http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx
using (TransactionScope scope = new TransactionScope())
{
....
}
Механизм транзакций в дотнете это очень интересный момент. Заметьте никакого отношения к вашему классу это как бы не имеет. Но если класс написан правильно то все должно работать.
#8 
Murr патриот06.10.10 01:44
Murr
NEW 06.10.10 01:44 
в ответ Nucleas 06.10.10 01:20
желательно внимательно прочитать
-----
Прочитано давно и достаточно внимательно. Работает в тех ограничениях которые приняты мелкомягкими по умолчанию. На моей базе элементарно обломится - юзеру разрешен только вызов процедур, выполнение каких-либо других действий не разрешено..
как бы не имеет
------
Это - да. Если хочешь поломать еще немного поломать голову, то представь аналог Аксесса, но не в плане объединения форнт-апп и базы, а в плане их разделения - интерфейсная часть - отдельная база, в которой нет реальных данных и она рулит транзакциями в другой базе, где хранятся данные...
#9 
Nucleas прохожий06.10.10 01:57
NEW 06.10.10 01:57 
в ответ Murr 06.10.10 01:44
выполнение каких-либо других действий не разрешено.. - получается что запустил сторед процедуру она что то поделала на неизвестных данных и выдала результат.(да забыл кстати она их и испртить может!!!)
сравнить его получается можно только с заведомо известным содержимым базы. Следовательно тестировать можно только на зараннее подготовленной базе. Получается ерунда.
Более того нет возможности использовать для тестирования другой версии базы как существующей или эмулятора по причине, что сторед процедуры могут выполняться по другому.
Напрашивается два решения или локальная версия базы или создания пользователя тестер с правами достаточными для тестирования.
#10 
Murr патриот06.10.10 02:12
Murr
NEW 06.10.10 02:12 
в ответ Nucleas 06.10.10 01:57
получается что запустил сторед процедуру она что то поделала на неизвестных данных и выдала результат.(да забыл кстати она их и испртить может!!!)
------
Именно так. В половине случаев - и результа то нет - тестируются 4 процедуры - SUDI...
сравнить его получается можно только с заведомо известным содержимым базы.
------
Ну наборы тестовых пересменных Я готов написать. Правда хотелось бы обойтись разумным минимумом.
локальная версия базы
------
В разработке она и так локальная. Хочется, однако, иметь тест, который можно гонять на любой базе. По крайней мере у меня так написаны инсталяционные скрипты - запускаешь и он там разбирается что удалить, что создать... данные, правда, не бэкапит, но это и не апдейтный скрип...
создания пользователя тестер с правами достаточными для тестирования.
-----
Надо обдумать. Лишний юзер есть лишний юзер, но в добавлении к 4 имеющимся вроде как не много...
Правда, похоже, для его придется делать его собственные процедуры - в чужую схему лазить не хорошо...
Думать надо. И уже не сегодня.
#11