Как (unit-)тестовое приложение с интенсивным использованием данных PL / SQL

наша команда готова юнит-тестировать новый код, написанный в рамках запущенного проекта, расширяющего существующую огромную систему Oracle.

система написана исключительно на языке PL/SQL, состоит из тысяч таблиц, сотен пакетов хранимых процедур, в основном получающих данные из таблиц и/или вставляющих / обновляющих другие данные.

наше расширение не является исключением. Большинство функций возвращают данные из довольно сложного Select statementa по многим взаимно связанным таблицам (с небольшим добавлена логика перед их возвратом) или сделать преобразование из одной сложной структуры данных в другую (усложненную по-другому).

каков наилучший подход к модульному тестированию такого кода?

нет модульных тестов для существующего кода. Хуже того, только пакеты, триггеры и представления управляются источником, структуры таблиц (включая материал "alter table" и необходимые преобразования данных развертываются по каналу, отличному от контроля версий). Это невозможно. изменить это в рамках нашего проекта.

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

Я был бы рад любому предложению или ссылке, чтобы помочь нам. Некоторые члены команды, как правило, устают, выясняя, как даже начать наш опыт модульного тестирования не охватывает данные PL/SQL интенсивные устаревшие системы (только те, которые "из книги" greenfield Java-проекты).

9
legacy oracle plsql tdd unit-testing

4 ответов

существует несколько различных инструментов тестирования для PL/SQL. Стивен Фейерштейн написал два из них,utplsql и тестер кода квеста для Oracle (ранее QUTE). Я большой поклонник utplsql, но у него больше нет активного сообщества поддержки (что позорно). Он также имеет тенденцию быть довольно многословным, особенно когда речь идет о настройке тестовых приспособлений. У него есть кардинальный виртуальный бытие pure PL/SQL пакеты; исходный код немного грубоват, но это FOSS.

QCTO поставляется с GUI, что означает-как и другие продукты Quest, т. е. жаба-это только Windows. Он не совсем автоматизирует генерацию тестовых данных, но предоставляет интерфейс для его поддержки. Также, как и другие продукты Quest, QCTO лицензируется, хотя есть бесплатная копия.

Стивен (раскрытие, он один из моих героев Oracle) написал сравнение функций всех инструментов тестирования PL/SQL. Очевидно, QOTC выходит верхом, но я думаю, что сравнение честное. проверить.

советы по тестовым светильникам в utplsql

управление тестовыми данными для модульного тестирования может быть настоящей болью в шее. К сожалению, utplsql не предлагает много, чтобы взвалить бремя. Так что

  • всегда проверяйте отношении известные значения:
    • избегайте использования СУБД;
    • попробуйте ограничить использование последовательности столбцов, значения которых не имеют значения;
    • даты также сложно. Избегайте жестких дат кодирования: используйте переменные, которые заполнены sysdate. Научитесь ценить add_months(), last_day(), interval, trunc(sysdate, 'MM'), etc.
  • изолировать тестовые данные от других пользователей. Строить его с нуля. Используйте отличительные значения везде, где это возможно.
  • только создать столько тестовых данных, сколько вам нужно. Объемное испытание отличается ответственность.
  • при тестировании процедур, которые изменяют данные, создают определенные записи для каждого модульного теста.
  • также: не полагайтесь на успешный выход из одного теста, чтобы обеспечить вход из другого теста.
  • при тестировании процедур, которые просто сообщают о записи обмена данными между модульными тестами, когда это необходимо.
  • Share framework data (например, ссылки на первичные ключи), когда это возможно.
  • использовать свободные текстовые поля (имена, описания, комментарии), чтобы определить, какие тесты использовать.
  • минимизировать работу по созданию новых записей:
    • назначать только значения, необходимые для набора тестов и ограничений таблицы;
    • использовать по умолчанию как можно больше;
    • Процедурализируйте как можно больше.

другие вещи, чтобы иметь в виду:

  • настройки тестового приспособление может быть трудоемким процессом. Если у вас много данных, подумайте о создании процедуры для настройки статических данных, которые можно запускать один раз за сеанс и включать только изменчивые данные в . Это особенно полезно при тестировании функций только для чтения.
  • помните, что создание тестовых данных является самостоятельным программированием и поэтому подвержено ошибкам.
  • используйте все функции utplsql. utAssert.EqQuery, utAssert.EqQueryValue, utAssert.EqTable, utAssert.EqTabCount и utAssert.Eq_RefC_Query все очень полезные функции, когда дело доходит до вывода значений изменчивых данных.
  • при диагностике тестового прогона, который не прошел так, как мы ожидали, может быть полезно иметь данные, которые были использованы. Поэтому подумайте о том, чтобы иметь пустоту ut_teardown процедура и очистка тестовых данных в начале ut_setup.

работа с унаследованным кодом

комментируя сообщение Гэри напомнил мне еще одну вещь, которую вы можете найди полезное. Стивен Ф написал ulplsql как реализацию PL / SQL JUnit, Авангарда Java первой части теста. Однако методы TDD также могут применяться к большим объемам устаревшего кода (в этом контексте устаревший код-это любой набор программ без каких-либо модульных тестов).

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

8

взять следующий сценарий

FUNCTION ret_count (local_client_id IN number) RETURN NUMBER IS
  v_ret number;
BEGIN
  SELECT count(*) INTO v_ret FROM table_1 WHERE client_id = local_client_id;
  RETURN v_ret;
END;

очень простая функция, но есть целый беспорядок вещей, которые могут пойти не так. Преобразования типов данных, индексация, статистика могут повлиять на пути запросов, производительность и, в некоторых случаях, ошибки. Существует также много свободных связей, таких как настройки сеанса (например, лингвистические предпочтения). Если кто-то пришел и добавил столбец "LOCAL_CLIENT_ID" в table_1, вся логика функции изменяется.

Я лично не чувствую, что TDD подходит для этой среды. У обзоров кода знающими людьми будет больше шансов поймать проблемы.

Если у вас есть деньги, то посмотрите на Oracle RAT (real application testing) для регрессионного тестирования.

4

Я использовал DbFit для модульного тестирования кода PL / SQL. Попробуй.

3

utPLSQL может помочь, но, похоже, вам нужен другой способ поддержания тестовых данных. Вы также можете посмотреть на Swingbench для этого.

1