Er zijn verschillende testtools voor PL/SQL. Steven Feuerstein heeft er twee geschreven, utplsql en Quest Code Tester voor Oracle (voorheen QUTE). Ik ben een grote fan van utplsql, maar het heeft niet langer een actieve ondersteuningsgemeenschap (wat jammer is). Het is ook nogal uitgebreid, vooral als het gaat om het opzetten van testopstellingen. Het heeft het kardinale virtuele van pure PL/SQL-pakketten; de broncode is een beetje knullig, maar het is FOSS.
QCTO wordt geleverd met een GUI, wat betekent dat het - net als andere Quest-producten, bijv. TOAD - alleen voor Windows is. Het automatiseert het genereren van testgegevens niet echt, maar het biedt een interface om dit te ondersteunen. Evenals andere Quest-producten heeft QCTO een licentie, hoewel er een freeware-exemplaar is.
Steven (onthulling, hij is een van mijn Oracle-helden) heeft een functievergelijking geschreven van alle PL/SQL-testtools. Uiteraard komt QOTC als beste uit de bus, maar ik denk dat de vergelijking eerlijk is. Bekijk het.
Advies over testopstellingen in utplsql
Het beheren van testgegevens voor unit-testen kan een echte pijn in de nek zijn. Helaas biedt utplsql niet veel om de last te dragen. Dus
- Test altijd tegen bekende waarden :
- Vermijd het gebruik van dbms_random;
- Probeer het gebruik van reeksen te beperken tot kolommen waarvan de waarden er niet toe doen;
- Data zijn ook lastig. Vermijd het hard coderen van datums:gebruik variabelen die zijn gevuld met sysdate. Leer
add_months()waarderen ,last_day(),interval,trunc(sysdate, 'MM'), enz.
- Isoleer de testgegevens van andere gebruikers. Bouw het vanaf nul. Gebruik waar mogelijk onderscheidende waarden.
- Maak alleen zoveel testgegevens aan als u nodig heeft. Volumetrische testen is een andere verantwoordelijkheid.
- Bij het testen van procedures die de gegevens wijzigen, worden specifieke records gemaakt voor elke eenheidstest.
- Ook:vertrouw niet op de succesvolle output van de ene test om de input van een andere test te leveren.
- Bij het testen van procedures die eenvoudigweg rapporteren aan de hand van gegevens, worden indien nodig records gedeeld tussen eenheidstests.
- Deel frameworkgegevens (bijv. primaire sleutels waarnaar wordt verwezen) waar mogelijk.
- Gebruik vrije tekstvelden (namen, beschrijvingen, opmerkingen) om te bepalen welke test of tests het record gebruiken.
- Minimaliseer het werk dat gepaard gaat met het maken van nieuwe records:
- Wijs alleen waarden toe die nodig zijn voor de testsuite en de beperkingen van de tabel;
- Gebruik zoveel mogelijk standaardwaarden;
- Procedurale zo veel mogelijk.
Andere dingen om in gedachten te houden:
- het opzetten van een proefopstelling kan een tijdrovende bezigheid zijn. Als je veel gegevens hebt, overweeg dan om een procedure te bouwen om de statische gegevens in te stellen die één keer per sessie kunnen worden uitgevoerd, en neem alleen vluchtige gegevens op in de
ut_setupzelf. Dit is vooral handig bij het testen van alleen-lezen functionaliteit. - onthoud dat het maken van testgegevens een programmeeroefening op zich is, en dus vatbaar voor bugs.
- gebruik alle functies van utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountenutAssert.Eq_RefC_Queryzijn allemaal erg handige functies als het gaat om het afleiden van de waarden van vluchtige gegevens. - bij het diagnosticeren van een testrun die niet verliep zoals we hadden verwacht, kan het handig zijn om over de gebruikte gegevens te beschikken. Overweeg dus om een holle
ut_teardownprocedure en het wissen van de testgegevens aan het begin vanut_setup.
Omgaan met verouderde code
Reageren op Gary's post deed me denken aan iets anders dat je misschien nuttig vindt. Steven F schreef uplsql als een PL/SQL-implementatie van JUnit, de Java-voorhoede van de Test First-beweging. De technieken van TDD kunnen echter ook worden toegepast op grote hoeveelheden legacy-code (in deze context is legacy-code elke reeks programma's zonder unittests).
Het belangrijkste om in gedachten te houden is dat je niet meteen alles onder unit-test hoeft te krijgen. Begin stapsgewijs. Bouw unit tests voor nieuwe dingen, Test eerst . Maak eenheidstests voor de bits die u gaat wijzigen voordat u de wijziging toepast, zodat u weet dat ze nog steeds werken nadat u de wijziging hebt aangebracht.
Er is veel over nagedacht op dit gebied, maar (onvermijdelijk als schandelijk) komt het vooral van de OO-programmeurs. Michael Feathers is het hoofdhoofdstuk. Lees zijn artikel Effectief werken met verouderde code . Als je het nuttig vindt, heeft hij vervolgens een boek met dezelfde naam geschreven.