Процедури модульного тестування програм на мові SQL PL з використанням інфраструктури db2unit в середовищі DB2 LUW

1. огляд
2. Завантаження і установка db2unit
3. Малюнок 1. Розділ Releases в репозитарії GitHub для завантаження стабільної версії db2unit
4. Малюнок 2. Встановлення інфраструктури db2unit на платформі Linux
5. визначення тесту
6. Малюнок 4. Відносини між різними компонентами архітектури xUnit
7. Малюнок 5. Компоненти тестового комплекту в db2unit
8. Розробка тестового комплекту
9. Лістинг 1. Приклад коду для створення об'єктів, що підлягають тестуванню
10. Лістинг 2. Тест 1: Перевірка конверсії 10 дол. США в колумбійські песо
11. Лістинг 3. Тест 2: Перевірка конверсії 2 дол. США в євро
12. Лістинг 4. Тест 3: Перевірка конверсії 10000 колумбійських песо в євро
13. Компіляція і виконання тестового комплекту
14. Малюнок 6. Виконання тестів в поточній схемі
15. Малюнок 7. ER-діаграма інфраструктури db2unit
16. Висновок
17. Ресурси для скачування

Введення в xUnit-інфраструктуру для мови програмування SQL PL

огляд

Розробка програмного забезпечення - це не лише написання програмного коду, а й етап життєвого циклу, який включає в себе різні дії, що виконуються із загальною метою - створення зрілого додатки. У цьому життєвому циклі є фаза тестування, яка після виконання тестів на різних рівнях створює певні показники. Ці показники надають інформацію про якість програмного коду, допомагаючи гарантувати, що цей код робить саме те, що від нього очікується. Модульне тестування - це частина вищезгаданої фази тестування, що має на меті виконання перевірок на рівні компонентів. Майже у кожного сучасного мови програмування є той чи інший інструмент модульного тестування. У цій статті описується інфраструктура модульного тестування для мови SQL PL.

Інфраструктура модульного тестування виконує серію тестів і витягує звіт про їх виконання, в якому для кожного тесту вказаний конкретний результат його виконання - успіх (Pass), відмова (Fail), збій (Error). Сучасні методології програмування, такі як екстремальне програмування, істотно підвищили значимість модульного тестування - вони привели до створення практики т.зв. "Розробки на основі тестування", яка в значній мірі спирається на інфраструктури модульного тестування. Ця методологія програмування надає великого значення тестування кожного компонента програми та написання тестів ще до початку написання коду самого додатка. Такий підхід сприяє написанню більш якісного коду і дає впевненість у тому, що цей код буде працювати запланованим чином.

Зазвичай тести для програм, написаних на мові SQL PL, виконуються в ручному режимі. Розробник викликає збережену процедуру (stored procedure) або визначену користувачем функцію (user-defined function) з різними параметрами, а потім перевіряє правильність отриманих результатів. Таким результатом може бути повернене значення або зміна даних в базі даних. Якщо реальна поведінка програми відрізняється від очікуваного, розробник змінює код, повторно розгортає його і знову перевіряє правильність отриманих результатів - і так до тих пір, поки програма не працюватиме коректно. Однак цей підхід породжує безліч проблем, оскільки виконуються тести не є відтвореними. Вони вимагають великих витрат часу; крім того, існує висока ймовірність пропустити регресивні зміни (тобто повторні виникнення раніше вже усунених помилок).

Для інфраструктур модульного тестування існує стандартна архітектура під назвою xUnit, що виросла з інфраструктури sUnit (для мови Smalltalk), яка, в свою чергу, лежить в основі добре відомої інфраструктури jUnit для технології Java ™. Ці інфраструктури, як і інші інфраструктури модульного тестування, корисні для тестування програмного забезпечення, написаного на тій же мові програмування. Однак вони не дуже добре підходять для тестування "зовнішнього" коду (написаного на інших мовах програмування), такого, як SQL-процедури, через те, що ці інфраструктури не використовують можливості бази даних. З цієї причини саме інфраструктура db2unit найкраще підходить для тестування коду на мові SQL PL в середовищі DB2.

Інфраструктура db2unit повністю написана на мові SQL PL для DB2 LUW, і відповідає архітектурі xUnit по структурі компонентів. У ній використовуються потужні можливості DB2, такі як автономні транзакції і модулі. Інфраструктура db2unit розміщена як публічний проект в репозитарії GitHub. Вона ліцензується відповідно до умов GPL V3.

Завантаження і установка db2unit

На момент написання цієї статті була випущена перша стабільна версія даної інфраструктури - db2unit v1. Ця версія доступна для завантаження в розділі Releases проекту db2unit в репозитарії GitHub.

Малюнок 1. Розділ Releases в репозитарії GitHub для завантаження стабільної версії db2unit

Пропоновані архівні файли обох типів (tar.gz і zip) містять необхідні файли для установки інфраструктури на будь-який підтримуваної платформі (Windows або Linux / UNIX / Mac OS X). Для установки db2unit необхідні:

• DB2 9.7 LUW або новішої версії (див. Розділ ресурси ).
• База даних для тестування, оскільки в цьому випадку краще мати виділену базу даних з фіктивними даними. Для такого невиробничого тестування ідеально підходить редакція DB2 Express-C.
• Повноваження dbadm для бази даних, в якій буде встановлена ​​інфраструктура db2unit; в якості альтернативного варіанту адміністратор баз даних може створити схему і надати необхідні права для відповідних об'єктів.
• У базі даних повинна бути встановлена ​​утиліта журналювання log4db2 для реєстрації подій в DB2 (див. Розділ ресурси ).

Коли необхідна база даних буде підготовлена, можна приступати до установки інфраструктури. Описувана інфраструктура містить установники різних типів для кожної платформи, яка підтримує DB2.

• Скрипти оболонки для Linux, UNIX і Mac OS X. середу DB2 повинна бути завантажена (наприклад,. $ {DB2INSTANCE} / sqllib / db2profile) і підключена до бази даних до запуску установника на виконання. Для виконання скрипта установки (рис. 2) його необхідно викликати за допомогою команди source, представленої точкою:. ./install.
• Для платформи Windows є два типи установників: один для CMD.exe (db2cmd.exe), а інший для PowerShell. У разі PowerShell необхідно завантажити середу DB2 за допомогою команди set-item -path env: DB2CLP -value "** $$ **".
• Незалежний від платформи спосіб установки цієї інфраструктури полягає в використанні установника CLP * Plus. Однак цей установник не виконує всіх перевірок середовища, які виконують інші установники.
• І, нарешті, середу db2unit також можна встановити в ручному режимі за допомогою почергового виконання всіх скриптів. Наприклад, можна послідовно відкривати кожен файл в клієнті IBM Data Studio і запускати його на виконання.

Малюнок 2. Встановлення інфраструктури db2unit на платформі Linux

Малюнок 3. Установка на платформі Windows завершена (db2cmd)

Якщо установка пройде успішно, буде показано повідомлення (рис. 3) із зазначенням імені бази даних, де була встановлена ​​інфраструктура, а також її версії і використовуваної схеми. Якщо в ході установки відбулися які-небудь помилки, буде показано описову повідомлення, що містить посилання на відповідний wiki-ресурс на сайті GitHub. Цей wiki-ресурс також містить відомості щодо виправлення помилок установки (див. Розділ ресурси ).

Для кожної випущеної окремо версії інфраструктури db2unit використовується спеціальна схема. Ця схема відповідає конкретної версії утиліти, що дозволяє розробнику виконувати в базі даних декілька версій однієї і тієї ж інфраструктури (див. Навчальний посібник, написаний Сержем рило (Serge Rielau), в розділі ресурси ). Для першої версії використовується схема з ім'ям db2unit_1. Всі функції і процедури цієї інфраструктури входять до складу публічного модуля з ім'ям db2unit, який зберігається у вищезгаданій схемі.

визначення тесту

В архітектурі xUnit визначені різні компоненти для інфраструктури модульного тестування, однак ця архітектура орієнтована на об'єктно-орієнтовані мови програмування. SQL PL - це процедурний мову, тому архітектура була адаптована до DB2 з використанням набору таблиць, схем і процедур, що зберігаються всередині модуля.

Малюнок 4. Відносини між різними компонентами архітектури xUnit

Розробник повинен реалізувати наступні компоненти архітектури xUnit.

1. Тестовий приклад (Test case) - це елементарний компонент архітектури xUnit. Він забезпечує взаємодію з тестованим об'єктом бази даних і перевіряє, чи мають певні предикати значення true (істина). У середовищі db2unit тестовий приклад представляється за допомогою процедури, що, яка відповідає наступним правилам:
   • Ім'я процедури починається з префікса TEST_.
   • Процедура не має параметрів.
2. Тестові фікстура (Test fixture) змінюють середу виконання до і після виконання кожного тестового прикладу або всіх тестових прикладів. В архітектурі xUnit визначено чотири типи тестових фікстур; кожна фікстура визначається за допомогою процедури, що без параметрів, яка має відповідне ім'я.
   • Перед виконанням усіх тестових прикладів (Before all): ONE_TIME_SETUP
   • Перед виконанням кожного тестового прикладу (Before): SETUP
   • Після виконання кожного тестового прикладу (After): TEAR_DOWN
   • Після виконання всіх тестових прикладів (After All): ONE_TIME_TEAR_DOWN
3. Тестовий комплект (Test suite) об'єднує кілька тестових прикладів і тестових фікстур; в DB2 він описується у вигляді схеми. Тестовий комплект може мати будь-яке ім'я, якщо DB2 підтримує це ім'я в якості імені для схеми. Кожна схема розглядається як окремий тестовий комплект.
4. Твердження (Assertions) - це предикати, які вказують, чи має певний предикат значення true (істина) або false (брехня). Твердження видається набором збережених процедур, включених в інфраструктуру. Розробник може розширити цей набір тверджень перевірками власних предикатів. Наявні твердження засновані на базових типах даних DB2: булеві (boolean), рядки (char, varchar), числа (smallint, integer, bigint), числа з плаваючою комою (float, double), дата / час (date, time, timestamp) ; вони описані в розділі API вищезгаданого wiki-ресурсу на сайті GitHub (див. розділ ресурси ). На додаток до цих тверджень інфраструктура db2unit має ще дві процедури: REGISTER_MESSAGE (асоціює сгенерированное SQL-виключення з повідомленням) і FAIL (автоматично розглядає тестовий приклад як завершився невдачею).

На додаток до елементів, які повинен визначити розробник, в архітектурі xUnit є інші компоненти, які включає і інфраструктура db2unit:

1. Виконавець тесту (Test runner) - видається збереженої процедурою з ім'ям RUN_SUITE.
2. При роботі виконавця тесту він генерує результат тесту (test result), що зберігається в таблиці з ім'ям REPORT_TESTS, яка зберігається в тій же схемі, що і тестовий комплект. Результат виконання тестового прикладу може належати до одного з наступних трьох типів.
   • Passed (Пройшов): виконання тесту не викликало ніяких помилок, а всі предикати мали значення true.
   • Failed (Не пройшов): виконання було успішним, однак як мінімум один предикат мав значення false.
   • Error (Помилка): в ході виконання тестового прикладу мала місце та чи інша проблема, яка викликала сигнал.
3. Всі виконання тестового комплекту зберігаються в таблиці EXECUTION_REPORTS, кожне таке виконання позначається ідентифікатором EXECUTION_ID.

Малюнок 5. Компоненти тестового комплекту в db2unit

На рис. 5 показана реалізація db2unit в DB2 (порівняйте її з архітектурою xUnit, показаної на рис. 4).

Ключовою особливістю цієї інфраструктури є незалежність транзакцій, які виконують тестовий приклад, від транзакції, яка здійснює запис результатів. В DB2 (і інших системах управління базами даних) ця функціональність носить назву автономних транзакцій (autonomous transaction). Транзакція, що виконує тестовий приклад, може перевірити необхідні предикати, а після цього виконати відкат транзакції (rollback). Якщо при цьому для запису результатів тесту не використовується автономна транзакція, то результати, збережені до моменту відкату, будуть втрачені. Збереження результатів тестування в рамках автономної транзакції забезпечує успішну запис інформації про тестування, а тестовий приклад зможе виконати повний відкат (для скасування внесених викликом тестованого алгоритму змін в базу даних).

Розробка тестового комплекту

У цьому розділі наведено приклад тестового комплекту для перевірки правильності роботи функції конверсії валюти. Цей приклад здатний працювати з базою даних, що містить наступні об'єкти.

• Таблиця з обмінними курсами між різними валютами і доларом США.
• Функція, що виконує конверсію валюти за допомогою передачі наступних параметрів: початкове значення, вихідна валюта, цільова валюта. Вона повертає цільове значення, виражене в цільової валюті.

Лістинг 1. Приклад коду для створення об'єктів, що підлягають тестуванню

CREATE TABLE US_DOLLAR_EXCHANGE_RATES (CURRENCY_NAME CHAR (3), RATE DECIMAL (10,2)) @ INSERT INTO US_DOLLAR_EXCHANGE_RATES VALUES ( 'EUR', 0.79), ( 'USD', 1), ( 'COP', 2052.50) @ CREATE OR REPLACE FUNCTION CONVERT_CURRENCY (SOURCE_VALUE DECIMAL, SOURCE_CURRENCY CHAR (3), TARGET_CURRENCY CHAR (3)) RETURNS DECIMAL (10,2) BEGIN DECLARE RET_VALUE DECIMAL (10,2); DECLARE US_DOLLARS DECIMAL (10,2); SET US_DOLLARS = (SELECT SOURCE_VALUE / RATE FROM US_DOLLAR_EXCHANGE_RATES WHERE CURRENCY_NAME = SOURCE_CURRENCY); SET RET_VALUE = (SELECT US_DOLLARS * RATE FROM US_DOLLAR_EXCHANGE_RATES WHERE CURRENCY_NAME = TARGET_CURRENCY); RETURN RET_VALUE; END @

На основі вищевказаних об'єктів ви зможете створити такі тестові приклади:

• Скільки колумбійських песо можна купити за 10 доларів США? (20525 колумбійських песо).
• Скільки євро можна купити за 2 долари США? (1,58 євро).
• Скільки євро можна купити за 10000 колумбійських песо? (3,84 євро).

Як правило, тестовий приклад складається з наступних трьох частин.

• Підготовка середовища - в цій частині проводиться оголошення і ініціалізація змінних, включаючи курсори, обробники і змінні інших типів. Крім того, ця частина може містити визначення очікуваного значення.
• Виконання операцій - після того як інфраструктура готова, об'єкт валиться тестування, а повернене значення зберігається в змінної (фактичне значення).
• Виклики процедур тверджень - очікуване значення і фактичне значення передаються в процедуру відповідного затвердження, яка перевіряє, чи збігаються ці значення.
  Примітка: порівняння - це не єдиний тип процедури затвердження, існуючий в інфраструктурі db2unit.

Наступні процедури, що містять реалізацію тестових прикладів. Вони створюються з опцією OR REPLACE, що забезпечує можливість повторного створення цих об'єктів (наприклад, при їх коригуванні).

Лістинг 2. Тест 1: Перевірка конверсії 10 дол. США в колумбійські песо

CREATE OR REPLACE METHOD TEST_1_USD_TO_COP BEGIN - Підготовка середовища. DECLARE EXPECTED_VALUE DECIMAL; DECLARE ACTUAL_VALUE DECIMAL; SET EXPECTED_VALUE = 20525; - Виконання операцій. SET ACTUAL_VALUE = CONVERT_CURRENCY (10, 'USD', 'COP'); - Виклики процедур тверджень. CALL DB2UNIT.ASSERT_DEC_EQUALS (EXPECTED_VALUE, ACTUAL_VALUE); END @

Лістинг 3. Тест 2: Перевірка конверсії 2 дол. США в євро

CREATE OR REPLACE METHOD TEST_2_USD_TO_EUR BEGIN - Підготовка середовища. DECLARE EXPECTED_VALUE DECIMAL; DECLARE ACTUAL_VALUE DECIMAL; SET EXPECTED_VALUE = 1.58; - Виконання операцій. - Примітка: Назва валюти має складатися з 3 букв. SET ACTUAL_VALUE = CONVERT_CURRENCY (2, 'USD', 'EURO'); - Calls assertions. CALL DB2UNIT.ASSERT_DEC_EQUALS (EXPECTED_VALUE, ACTUAL_VALUE); END @

Лістинг 4. Тест 3: Перевірка конверсії 10000 колумбійських песо в євро

CREATE OR REPLACE METHOD TEST_3_COP_TO_EUR BEGIN - Підготовка середовища. DECLARE EXPECTED_VALUE DECIMAL; DECLARE ACTUAL_VALUE DECIMAL; - Примітка: це вигадане очікуване значення. SET EXPECTED_VALUE = 4; - Виконання операцій. SET ACTUAL_VALUE = CONVERT_CURRENCY (10000, 'COP', 'EUR'); - Виклики процедур тверджень. CALL DB2UNIT.ASSERT_DEC_EQUALS ( 'Colombian Pesos to Euros', EXPECTED_VALUE, ACTUAL_VALUE); END @

Необхідно заздалегідь знати тип даних тестованого значення, щоб викликати належну процедуру затвердження для виконання в базі даних. Процедура, яку викликали перевірки предиката, повинна відповідати типу даних; в іншому випадку DB2 генерує помилку.

Всі процедури затвердження, що надаються інфраструктурою, здатні в якості свого першого параметра отримувати описову повідомлення. Це повідомлення відображається в тому випадку, якщо процедура затвердження завершилася невдачею. Це особливо корисно для виявлення джерела проблеми, якщо в одному тестовому прикладі здійснюється виклик великої кількості тверджень.

Компіляція і виконання тестового комплекту

Готовий код тестових прикладів можна виконати з метою створення відповідних об'єктів в базі даних (збережених процедур для тестів і їх залежностей). Цей процес виконується так само, як створюється в DB2 будь-яка інша процедура, що зберігається. Це можна зробити за допомогою CLP, Data Studio або будь-якого іншого інструменту, який виконує DDL-скрипти.

Отже, тести в базі даних створені, і їх необхідно виконати. Виконання тестового комплекту здійснює процедура з ім'ям DB2UNIT.RUN_SUITE. Описувана інфраструктура надає два способи виконання тестового комплекту: послідовний, при якому тестові приклади виконуються в алфавітному порядку, і випадковий, коли при кожному виконанні використовується інший порядок тестових прикладів. Для установки фіксованого порядку виконання необхідно викликати наступну процедуру:
CALL DB2UNIT.RANDOM_SORT (FALSE).

За замовчуванням виконання тестового комплекту включає в себе виконання всіх тестових прикладів, визначених у відповідній схемі. Проте, можна виконати і один певний тестовий приклад. Для цього при виклику виконавця тесту необхідно вказати ім'я цього прикладу.

Порядок випадкового виконання вмісту тестового комплекту реєструється в базі даних. Цей же довільний порядок можна згодом відтворити для того ж тестового комплекту. Для цього при виклику виконавця тесту необхідно вказати ідентифікатор EXECUTION_ID, відповідний попереднього виконання, наприклад:

• Виконання тестового комплекту:
  CALL DB2UNIT.RUN_SUITE (TEST_SUITE_NAME)
• Виконання Певного тестового прикладу з тестового комплекту:
  CALL DB2UNIT.CALL DB2UNIT.RUN_SUITE (TEST_SUITE_NAME, TEST_NAME => TEST_CASE_NAME)
• Виконання тестового комплекту в такому ж порядку, як і в попередньому виконанні:
  CALL DB2UNIT.RUN_SUITE (TEST_SUITE_NAME, EXECUTION_ID)

RUN_SUITE - це основна процедура інфраструктури db2unit. Вона виконує безліч перевірок і викликає іншу процедуру для виконання тестового комплекту. У розділі Architecture (архітектура) вищезгаданого wiki-ресурсу на сайті GitHub представлена ​​циклограмма, пояснює кожен крок цієї процедури, що (див. Розділ ресурси ).

Як зазначено в цьому розділі, ідентифікатор виконання носить ім'я EXECUTION_ID, а його значення є випадковим числом, яке генерується інфраструктурою. Це унікальне число дозволяє ідентифікувати певне виконання тестового комплекту і використовувати його для отримання звіту про виконання або для відтворення такого ж порядку тестових прикладів при повторному виконанні цього тестового комплекту.

В кінці виконання тестового комплекту розробник отримує звіт з результатами тверджень для кожного тестового прикладу і зведення по виконанню із зазначенням результатів виконання тестових прикладів (Passed, Failed, Error - пройшов, не пройшов, завершився з помилкою).

Малюнок 6. Виконання тестів в поточній схемі

На рис. 6 показаний звіт по виконанню тестового комплекту. Цей тестовий комплект спеціально розроблений, щоб показати результати всіх типів (пройшов, не пройшов, завершився з помилкою). У верхній частині екрану перший набір результатів (Result set) демонструє вихідну інформацію тестів. У першому стовпчику показано, яка збережена процедура (тестовий приклад) виконувалася і яка тестова фікстура при цьому застосовувалася (before all, after all). У другому стовпці показано кінцевий стан виконання тесту (Passed, Failed, Error). У третьому стовпці показано час, який знадобився для виконання даного тестового прикладу. У четвертому стовпці показані повідомлення; це може бути ім'я процедури, повідомлення від затвердження або повідомлення про НЕ перехоплений SQL-виключення. В останніх рядках цього набору результатів демонструється зведення з даного виконання. Ця інформація зберігається в таблиці REPORT_TEST в тій же схемі тестового комплекту.

Другий набір результатів носить більш загальний характер, він показує, який тестовий комплект виконувався, його згенерований ідентифікатор EXECUTION_ID, а також повне час, який знадобився для виконання всього цього комплекту. Ця інформація зберігається в таблиці EXECUTION_REPORT схеми db2unit schema.

До теперішнього моменту в цій статті розглядалися базові можливості інфраструктури db2unit, проте розробнику необхідно знати і про інших, розширених, можливості цієї інфраструктури.

• За замовчуванням інфраструктура працює в режимі автономних транзакцій, що дозволяє мати різні межі між тестованим об'єктом і інфраструктурою тестування. Проте цю опцію можна деактивувати, що дозволяє виконувати операції db2unit в межах однієї і тієї ж транзакції з тестованим об'єктом:
  CALL DB2UNIT.SET_AUTONOMOUS (FALSE)
• Інфраструктура db2unit базується на простій схемі таблиць.

Малюнок 7. ER-діаграма інфраструктури db2unit

• Якщо виконання тестового комплекту примусово припиняється, необхідно очистити середу перед тим, як знову запускати будь-якої тестовий комплект в тому ж сеансі DB2 (db2bp). Ця вимога пояснюється тим, що дана інфраструктура використовує велику кількість змінних сеансу.
  CALL DB2UNIT.CLEAN ()
• При кожному виконанні тестового комплекту створюється відповідна блокування для запобігання паралельних виконань одного і того ж тестового комплекту. Це блокування встановлюється в той момент, коли виконання починається, і знімається після завершення генерації звіту. Якщо виконання тестового комплекту примусово припиняється в проміжку між цими моментами, вищевказану блокування необхідно зняти в ручному режимі; в іншому випадку інфраструктура обробляє цю ситуацію точно так же, як при наявності поточного виконання тестового комплекту. Якщо одночасно були примусово припинено кілька тестових комплектів, то всі блокування в базі даних можна зняти одночасно.
  CALL DB2UNIT.RELEASE_LOCK ( 'MY_SUITE')
  CALL DB2UNIT.RELEASE_LOCKS ()
• Інфраструктура включає набір тверджень для основних типів даних; проте розробник може створити власні твердження і інтегрувати їх з інфраструктурою.
• Нарешті, розробник може повернути в початковий стан всю конфігурацію інфраструктури db2unit і привести її до стану на момент установки (вихідна конфігурація). В результаті цього будуть видалені всі виконання, реєстрації тестових комплектів, блокування та інші об'єкти.
  CALL DB2UNIT.RESET_TABLES ()

Рекомендації з написання тестових прикладів

Щоб швидко створювати ефективні тестові приклади, необхідно враховувати наступні міркування.

1. Всі тестові приклади належать до тестового комплекту. Якщо тестові приклади створюються без схеми, вони належать до поточної схемою, яка зазвичай відповідає імені поточного користувача.
2. Тестовий комплект може містити всього один тестовий приклад без тестових фікстур.
3. Ім'я тестового прикладу не повинна бути укладена в лапки і завжди повинно складатися з великих літер. Продукт DB2 чутливий до регістру в іменах об'єктів; щоб уникнути помилок необхідно дозволити продукту DB2 зберігати імена, представлені великими літерами.
4. Тестові комплекти повинні мати високу ступінь зв'язності; не всі тести повинні входити до складу одного тестового комплекту. Рекомендується групувати тестові приклади відповідно до їх характеру; це прискорює виконання і спрощує виявлення помилок.
5. Хороший спосіб створення нового тестового комплекту полягає в застосуванні принципу "розділяй і володарюй". Спочатку розробіть тестові фікстура і виконайте їх в базі даних. Вони повинні виконуватися успішно і без помилок; тільки після цього слід рухатися далі. Домігшись коректної роботи тестових фікстур, додайте до тестового комплекту будь-яку процедуру і виконаєте цей комплект знову для підтвердження правильності програмного коду. Повторіть цей процес для кожного тестового прикладу.
6. При створенні нових тестових комплектів їх необхідно виконувати послідовно. Коли комплекти стануть стабільними, послідовний порядок виконання можна замінити випадковим. Така практика важлива для скорочення кількості помилок, породжуваних недостатньою ізоляцією тестових прикладів.
7. Починайте розробку тестових прикладів з деактивованою опцією автономних транзакцій. Це зменшить ймовірність очікування блокування та інших побічних проблем.
8. Імена тестових прикладів повинні бути не короткими і не довгими, але лаконічними і описовими.
9. Кожен тестовий приклад повинен містити не менше одного виклику будь-якої з наступних процедур:
   • Register message - Для тестових прикладів, процес яких успішно завершується без валідації будь-якого предиката. Це типова ситуація, коли тестовий приклад переконується у відсутності генеруються сигналів.
   • Fail - Для тестових прикладів, яким немає необхідності відчувати умови конкретного предиката (IF, ELSEIF, ELSE; ніколи не доходить до блоку else), внаслідок чого тестовий приклад повинен завершитися невдачею (fail).
   • Assertions - Цей набір процедур підтверджує правильність предикатів.
10. В інфраструктурі db2unit є процедура, яка реєструє описову повідомлення, відповідне мети тестового прикладу. У разі подання сигналу інфраструктура db2unit перехоплює його, а звіт про виконання тесту показує це повідомлення після завершення виконання. Виклик цієї процедури повинен бути першим викликом у кожному тестовому прикладі.
    CALL DB2UNIT.REGISTER_MESSAGE (MESSAGE);
11. При кожному виклику затвердження може бути передано описову повідомлення. Це спрощує розпізнавання проблеми в результаті тесту.
    CALL DB2UNIT.ASSERT_INT_EQUALS ( 'Test A, comparing a with b', EXPECTED, ACTUAL);
12. При виклику затвердження значення, передані як аргументи, повинні бути заздалегідь задані в локальних змінних. Не рекомендується передавати в утвердження в якості аргументів функції, арифметичні операції або конкатенації. У заданих значеннях можуть бути присутніми помилки, внаслідок чого в процесі налагодження буде важче виявити джерело проблеми. Нижче наведені приклади погано заданих викликів:
    CALL DB2UNIT.ASSERT_INT_EQUALS (EXPECTED, MOD (5, 2))
    CALL DB2UNIT.ASSERT_INT_EQUALS (EXPECTED, 'Text' || null)
13. Щоб отримати трасування виконання, рекомендується записувати повідомлення в журнальну таблицю, в журнал db2diag.log, в який-небудь файл або в стандартний висновок. Призначення утиліти log4db2 полягає в тому, щоб реєструвати журнальні повідомлення в інших місцях. Наявність цієї утиліти є необхідною умовою при установці інфраструктури db2unit.
    CALL LOGGER.GET_LOGGER ( 'myStoredProcedure', ID);
    CALL LOGGER.INFO (ID, 'Informative message);
14. Для написання повідомлень утиліта log4db2 використовує концепцію logger-компонента (реєстратора). На початковому етапі написання тестів реєстратори можна конфігурувати з високим рівнем деталізації журналирования. Після того, як тестові приклади стануть стабільними, рівень деталізації можна знизити.
15. Рекомендується залишати налагоджувальні повідомлення всередині програмного коду, а не видаляти їх, коли цей код буде готовий і стане працювати належним чином. Ці повідомлення можна буде використовувати в разі повторної появи помилок, наприклад, при рефакторінгу програмного коду або при внесенні до нього змін.

Висновок

Зберігаються в базі даних програми, такі як збережені процедури і визначені користувачем функції, повинні бути високої якості, оскільки вони є загальними для всіх додатків, що звертаються до цієї бази даних. Інфраструктура модульного тестування db2unit допомагає розробнику створювати більш стійкий програмний код, надаючи кошти для автоматизації виконання тестів. Ця інфраструктура заснована на стандарті xUnit, що прискорює її освоєння і спрощує навчання для фахівців, знайомих з jUnit або аналогічними інфраструктурами тестування. Інфраструктуру db2unit можна з легкістю вбудувати в процес безперервної інтеграції програмного забезпечення і використовувати в будь-якій групі розробки, що орієнтується на такі парадигми, як екстремальне програмування або DevOps. Утиліта log4db2 в поєднанні з db2unit надає цілий ряд можливостей для підвищення надійності коду, написаного на мові SQL PL.

Ресурси для скачування

Схожі тими

• Оригінал статті: Unit test SQL PL routines by using db2unit framework in DB2 LUW .
• Online Rolling Application Upgrades (Стаття в блозі SQL Tips for DB2 LUW, 20 лютого 2012 року): У статті пояснюється, як мати кілька версій програм на мові SQL PL в базі даних DB2.
• Test-Driven Development (Wikipedia): Додаткові відомості про стратегію програмування "Розробка на основі тестування".
• xUnit frameworks (Wikipedia): Опис усіх компонентів архітектури xUnit.
• FAQs of db2unit : Опис поширених проблем, що виникають при установці інфраструктури db2unit.
• API of db2unit : Список наявних тверджень для перевірки предикатів.
• Sequence diagram : ER-діаграма інфраструктури db2unit.
• db2unit - Розділ Releases в репозитарії GitHub для завантаження стабільної версії інфраструктури.
• log4db2 - Розділ Releases в репозитарії GitHub для завантаження стабільної версії утиліти журналирования.
• DB2 Express-C - Безкоштовна редакція СУБД для розробки, розгортання і дистрибуції.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів