Существует несколько различных инструментов тестирования для PL / SQL. Стивен Фюрштайн написал два из них, utplsql и Quest Code Tester для Oracle (ранее QUTE). Я большой поклонник utplsql, но у него больше нет активного сообщества поддержки (что обидно). Он также довольно многословный, особенно когда речь идет о настройке тестовых приборов. Он имеет кардинальное виртуальное значение чистых пакетов PL / SQL ; исходный код немного грубоват, но это FOSS.
QCTO поставляется с графическим интерфейсом, что означает - как и другие продукты Quest, т.е. TOAD - это только Windows. Он не совсем автоматизирует генерацию тестовых данных, но предоставляет интерфейс для его поддержки. Также как и другие продукты Quest, QCTO лицензируется, хотя есть бесплатная копия.
Стивен (рассказывает, он один из моих героев в Oracle) написал сравнение всех инструментов тестирования PL / SQL. Очевидно, что QOTC выходит на первое место, но я думаю, что сравнение честное. Проверьте это.
Рекомендации по испытательным приборам в utplsql
Управление данными испытаний для модульного тестирования может быть настоящей болью в шее. К сожалению, utplsql мало что может взять на себя. Так
- Всегда проверять по известным значениям :
- Избегайте использования dbms_random;
- Попробуйте ограничить использование последовательностей столбцами, значения которых не имеют значения;
- Даты тоже хитры. Избегайте жестко запрограммированных дат: используйте переменные, которые заполнены sysdate. Научитесь ценить
add_months(), last_day(), interval, trunc(sysdate, 'MM') и т. Д.
- Изолировать тестовые данные от других пользователей. Постройте это с нуля. По возможности используйте отличительные значения.
- Создайте столько тестовых данных, сколько вам нужно. Объемное тестирование - это другая ответственность.
- При тестировании процедур, которые изменяют данные, создавайте конкретные записи для каждого модульного теста.
- Также: не полагайтесь на успешный вывод из одного теста, чтобы обеспечить ввод из другого теста.
- При тестировании процедур, которые просто сообщают о записях обмена данными между модульными тестами, когда это необходимо.
- По возможности обмениваться данными инфраструктуры (например, ссылочными первичными ключами).
- Используйте свободные текстовые поля (имена, описания, комментарии), чтобы определить, какой тест или тесты используют запись.
- Минимизируйте работу, связанную с созданием новых записей:
- Присваивать только те значения, которые необходимы для набора тестов и ограничений таблицы;
- Максимально использовать значения по умолчанию;
- Процедура как можно больше.
Другие вещи, которые следует иметь в виду:
- установка тестового прибора может занять много времени. Если у вас много данных, подумайте о создании процедуры для настройки статических данных, которые можно запускать один раз за сеанс, и включать в себя только изменчивые данные в самом
ut_setup. Это особенно полезно при тестировании функций только для чтения.
- Помните, что создание тестовых данных - это самостоятельное программирование, поэтому оно подвержено ошибкам.
- использовать все функции utplsql.
utAssert.EqQuery, utAssert.EqQueryValue, utAssert.EqTable, utAssert.EqTabCount и utAssert.Eq_RefC_Query - все это очень полезные функции для определения значений изменчивых данных.
- при диагностике теста, который не прошел так, как мы ожидали, может быть полезно иметь данные, которые были использованы. Так что подумайте о том, чтобы провести пустую процедуру
ut_teardown и очистить тестовые данные в начале ut_setup.
Работа с устаревшим кодом
Комментарий к сообщению Гэри напомнил мне еще одну вещь, которую вы можете найти полезной. Стивен Ф. написал ulplsql как PL / SQL-реализацию JUnit, авангарда Java движения Test First. Однако методы TDD могут также применяться к большим объемам устаревшего кода (в этом контексте устаревший код представляет собой любой набор программ без каких-либо модульных тестов).
Главное, что нужно иметь в виду, это то, что вам не нужно сразу же проходить все юнит-тестирование. Начните постепенно. Сборка юнит-тестов для нового материала, Test First . Создайте модульные тесты для битов, которые вы собираетесь изменить, прежде чем применить изменение, чтобы вы знали, что они все еще работают после того, как вы сделали изменение.
В этой области много размышлений, но (неизбежно, если не стыдно), это в основном исходит от ОО-программистов. Майкл Фезерс - главный парень. Прочитайте его статью Эффективная работа с устаревшим кодом . Если вы найдете это полезным, он впоследствии написал книгу с тем же именем.