Има няколко различни тестови инструмента за PL/SQL. Стивън Фойерщайн е написал две от тях, utplsql и Quest Code Tester за Oracle (по-рано QUTE). Аз съм голям фен на utplsql, но вече няма активна общност за поддръжка (което е жалко). Освен това има тенденция да бъде доста многословен, особено когато става въпрос за настройка на тестови устройства. Той наистина има основната виртуалност на чисти PL/SQL пакети; изходният код е малко корав, но е FOSS.
QCTO идва с GUI, което означава - подобно на други продукти на 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.
Работа с наследен код
Коментирането на публикацията на Гари ми напомни за още едно нещо, което може да намерите за полезно. Стивън Ф написа uplsql като PL/SQL реализация на JUnit, Java авангардът на движението Test First. Техниките на TDD обаче могат да бъдат приложени и към големи количества наследен код (в този контекст наследеният код е всеки набор от програми без никакви тестове на единици).
Ключовото нещо, което трябва да имате предвид е, че не е нужно да подлагате всичко на модулен тест веднага. Започнете постепенно. Създайте модулни тестове за нови неща, Първо тествайте . Изградете модулни тестове за битовете, които ще промените, преди да приложите промяната, така че да знаете, че продължават да работят, след като сте направили промяната.
Има много мисли в тази област, но (неизбежно, макар и срамно) те идват главно от OO програмистите. Майкъл Федърс е главният човек. Прочетете неговата статия Ефективна работа с наследен код . Ако го намерите за полезно, той впоследствие написа книга със същото име.
