Der er flere forskellige testværktøjer til PL/SQL derude. Steven Feuerstein har skrevet to af dem, utplsql og Quest Code Tester for Oracle (tidligere QUTE). Jeg er stor fan af utplsql, men det har ikke længere et aktivt supportfællesskab (hvilket er en skam). Det plejer også at være ret omfattende, især når det kommer til opsætning af testarmaturer. Det har den kardinalvirtuelle at være rene PL/SQL-pakker; kildekoden er en smule knudret, men det er FOSS.
QCTO kommer med en GUI, hvilket betyder - ligesom andre Quest produkter, dvs TOAD - det er kun Windows. Det automatiserer ikke ligefrem generering af testdata, men det giver en grænseflade til at understøtte det. Ligesom andre Quest-produkter er QCTO licenseret, selvom der er en freeware-kopi.
Steven (afsløring, han er en af mine Oracle-helte) har skrevet en funktionssammenligning af alle PL/SQL-testværktøjerne. Naturligvis kommer QOTC ud i top, men jeg synes, sammenligningen er ærlig. Tjek det ud.
Rådgivning om testarmaturer i utplsql
Håndtering af testdata til enhedstestning kan være en reel smerte i nakken. Desværre tilbyder utplsql ikke meget til at bære byrden. Så
- Test altid mod kendte værdier :
- Undgå at bruge dbms_random;
- Prøv at begrænse brugen af sekvenser til kolonner, hvis værdier er ligegyldige;
- Datoer er også vanskelige. Undgå hårdkodning af datoer:brug variabler, der er udfyldt med sysdate. Lær at sætte pris på
add_months(),last_day(),interval,trunc(sysdate, 'MM')osv.
- Isoler testdataene fra andre brugere. Byg det fra bunden. Brug karakteristiske værdier, hvor det er muligt.
- Opret kun så mange testdata, som du har brug for. Volumetrisk test er et andet ansvar.
- Når testprocedurer, der ændrer dataene, opretter specifikke poster for hver enhedstest.
- Desuden:Stol ikke på, at det vellykkede output fra én test giver input fra en anden test.
- Når der testes procedurer, der blot rapporterer mod data, deler man poster mellem enhedstests, når det er relevant.
- Del rammedata (f.eks. refererede primærnøgler), når det er muligt.
- Brug fritekstfelter (navne, beskrivelser, kommentarer) til at identificere, hvilken eller hvilke test der bruger posten.
- Minimer arbejdet med at oprette nye poster:
- Tildel kun værdier, som er nødvendige for testpakken og tabellens begrænsninger;
- Brug standardværdier så meget som muligt;
- Proceduraliser så meget som muligt.
Andre ting at huske på:
- Opsætning af et testarmatur kan være en tidskrævende øvelse. Hvis du har mange data, så overvej at bygge en procedure til opsætning af de statiske data, som kan køres én gang pr. session og kun inkludere flygtige data i
ut_setupsig selv. Dette er især nyttigt, når du tester skrivebeskyttet funktionalitet. - husk, at oprettelse af testdata er en programmeringsøvelse i sig selv og derfor udsat for fejl.
- brug alle funktionerne i utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountogutAssert.Eq_RefC_Queryer alle meget nyttige funktioner, når det kommer til at udlede værdierne af flygtige data. - Når man diagnosticerer en testkørsel, som ikke gik, som vi havde forventet, kan det være nyttigt at have de anvendte data. Så overvej at have en hul
ut_teardownprocedure og rydning af testdata ved starten af ut_setup.
Håndtering af ældre kode
At kommentere på Garys indlæg mindede mig om en anden ting, du kan finde nyttig. Steven F skrev ulplsql som en PL/SQL-implementering af JUnit, Java-fortrop i Test First-bevægelsen. TDD-teknikkerne kan dog også anvendes på store mængder ældre kode (i denne sammenhæng er ældre kode ethvert sæt programmer uden enhedstest).
Den vigtigste ting at huske på er, at du ikke behøver at få alt under enhedstest med det samme. Start trinvist. Byg enhedstests for nye ting, Test først . Byg enhedstests for de bits, du vil ændre, før du anvender ændringen, så du ved, at de stadig virker, efter du har foretaget ændringen.
Der er mange tanker på dette område, men (uundgåeligt hvis skammeligt) kommer det hovedsageligt fra OO-programmørerne. Michael Feathers er hovedpersonen. Læs hans artikel Arbejd effektivt med ældre kode . Hvis du finder det nyttigt, skrev han efterfølgende en bog af samme navn.