Det finns flera olika testverktyg för PL/SQL där ute. Steven Feuerstein har skrivit två av dem, utplsql och Quest Code Tester för Oracle (tidigare QUTE). Jag är ett stort fan av utplsql, men det har inte längre en aktiv supportgemenskap (vilket är synd). Det brukar också vara ganska mångsidigt, speciellt när det gäller att sätta upp testfixturer. Det har den kardinalvirtuella av att vara rena PL/SQL-paket; källkoden är lite knotig men det är FOSS.
QCTO kommer med ett GUI, vilket betyder - precis som andra Quest-produkter, dvs TOAD - det är endast Windows. Det automatiserar inte exakt generering av testdata, men det tillhandahåller ett gränssnitt för att stödja det. Liksom andra Quest-produkter är QCTO licensierad även om det finns ett gratisprogram.
Steven (avslöjande, han är en av mina Oracle-hjältar) har skrivit en jämförelse av alla PL/SQL-testverktyg. Självklart kommer QOTC ut toppar, men jag tror att jämförelsen är ärlig. Kolla in det.
Råd om testfixturer i utplsql
Att hantera testdata för enhetstestning kan vara en rejäl smärta i nacken. Tyvärr erbjuder utplsql inte mycket för att axla bördan. Så
- Testa alltid mot kända värden :
- Undvik att använda dbms_random;
- Försök att begränsa användningen av sekvenser till kolumner vars värden inte spelar någon roll;
- Datum är också knepiga. Undvik hårdkodning av datum:använd variabler som är fyllda med sysdate. Lär dig att uppskatta
add_months(),last_day(),interval,trunc(sysdate, 'MM')osv.
- Isolera testdata från andra användare. Bygg den från grunden. Använd distinkta värden där det är möjligt.
- Skapa bara så mycket testdata som du behöver. Volumetrisk testning är ett annat ansvar.
- När testprocedurer som ändrar data skapas specifika poster för varje enhetstest.
- Också:Lita inte på att det lyckade resultatet från ett test ska ge input från ett annat test.
- Vid testprocedurer som helt enkelt rapporterar mot data delar poster mellan enhetstester när så är lämpligt.
- Dela ramdata (t.ex. refererade primärnycklar) när det är möjligt.
- Använd fritextfält (namn, beskrivningar, kommentarer) för att identifiera vilket eller vilka tester som använder posten.
- Minimera arbetet med att skapa nya poster:
- Tilldela endast värden som är nödvändiga för testsviten och tabellens begränsningar;
- Använd standardvärden så mycket som möjligt;
- Procedurisera så mycket som möjligt.
Andra saker att tänka på:
- att sätta upp en testfixtur kan vara en tidskrävande övning. Om du har mycket data, överväg att bygga en procedur för att ställa in statisk data som kan köras en gång per session och endast inkludera flyktiga data i
ut_setupsig. Detta är särskilt användbart när du testar skrivskyddad funktionalitet. - kom ihåg att att skapa testdata är en programmeringsövning i sig, och därför benägen för buggar.
- använd alla funktioner i utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountochutAssert.Eq_RefC_Queryär alla mycket användbara funktioner när det gäller att sluta sig till värdena för flyktiga data. - När man diagnostiserar en testkörning som inte gick som vi förväntade oss kan det vara användbart att ha de data som användes. Så överväg att ha en ihålig
ut_teardownproceduren och rensa testdata i början avut_setup.
Hantera äldre kod
Att kommentera Garys inlägg påminde mig om en annan sak som du kan ha nytta av. Steven F skrev ulplsql som en PL/SQL-implementering av JUnit, Java-avantgarden i Test First-rörelsen. Teknikerna för TDD kan emellertid också tillämpas på stora mängder äldre kod (i detta sammanhang är äldre kod vilken uppsättning program som helst utan några enhetstester).
Det viktigaste att tänka på är att du inte behöver testa allt omedelbart. Börja stegvis. Bygg enhetstester för nya saker, Testa först . Bygg enhetstester för de bitar du ska ändra innan du tillämpar ändringen, så att du vet att de fortfarande fungerar efter att du har gjort ändringen.
Det finns en hel del tankar på detta område, men (oundvikligen om skamligt) kommer det främst från OO-programmerarna. Michael Feathers är huvudpersonen. Läs hans artikel Arbeta effektivt med äldre kod . Om du tycker att det är användbart skrev han senare en bok med samma namn.