Es gibt mehrere verschiedene Testwerkzeuge für PL/SQL. Steven Feuerstein hat zwei davon geschrieben, utplsql und Quest Code Tester für Oracle (früher QUTE). Ich bin ein großer Fan von utplsql, aber es gibt keine aktive Support-Community mehr (was schade ist). Es neigt auch dazu, ziemlich ausführlich zu sein, besonders wenn es um die Einrichtung von Testvorrichtungen geht. Es hat den Kardinaleffekt, reine PL/SQL-Pakete zu sein; Der Quellcode ist ein bisschen knorrig, aber es ist FOSS.
QCTO wird mit einer GUI geliefert, was bedeutet, dass es - wie andere Quest-Produkte, z. B. TOAD - nur Windows ist. Es automatisiert die Generierung von Testdaten nicht gerade, aber es bietet eine Schnittstelle, um dies zu unterstützen. Wie andere Quest-Produkte ist auch QCTO lizenziert, obwohl es eine Freeware-Kopie gibt.
Steven (Offenlegung, er ist einer meiner Oracle-Helden) hat einen Funktionsvergleich aller PL/SQL-Testwerkzeuge geschrieben. Offensichtlich schneidet QOTC am besten ab, aber ich denke, der Vergleich ist ehrlich. Sieh es dir an.
Ratschläge zu Testvorrichtungen in utplsql
Die Verwaltung von Testdaten für Unit-Tests kann eine echte Nervensäge sein. Leider bietet utplsql nicht viel, um die Last zu schultern. Also
- Immer gegen bekannte Werte testen :
- Vermeiden Sie die Verwendung von dbms_random;
- Versuchen Sie, die Verwendung von Sequenzen auf Spalten zu beschränken, deren Werte keine Rolle spielen;
- Daten sind auch schwierig. Vermeiden Sie hartcodierte Daten:Verwenden Sie Variablen, die mit sysdate gefüllt sind. Lernen Sie
add_months()zu schätzen ,last_day(),interval,trunc(sysdate, 'MM')usw.
- Isolieren Sie die Testdaten von anderen Benutzern. Bauen Sie es von Grund auf neu. Verwenden Sie nach Möglichkeit eindeutige Werte.
- Erstellen Sie nur so viele Testdaten, wie Sie benötigen. Volumetrische Tests sind eine andere Verantwortung.
- Beim Testen von Prozeduren, die die Daten ändern, werden spezifische Datensätze für jeden Unit-Test erstellt.
- Außerdem:Verlassen Sie sich nicht auf die erfolgreiche Ausgabe eines Tests, um die Eingabe eines anderen Tests bereitzustellen.
- Beim Testen von Prozeduren, die einfach gegen Daten berichten, werden gegebenenfalls Datensätze zwischen Komponententests ausgetauscht.
- Teilen Sie Rahmendaten (z. B. referenzierte Primärschlüssel) wann immer möglich.
- Verwenden Sie Freitextfelder (Namen, Beschreibungen, Kommentare), um anzugeben, welcher Test oder welche Tests den Datensatz verwenden.
- Minimieren Sie den Arbeitsaufwand beim Erstellen neuer Datensätze:
- Weisen Sie der Testsuite und den Einschränkungen der Tabelle nur Werte zu, die notwendig sind;
- Verwenden Sie so weit wie möglich Standardwerte;
- Prozeduralisieren Sie so viel wie möglich.
Andere zu beachtende Dinge:
- Das Einrichten einer Testvorrichtung kann eine zeitaufwändige Übung sein. Wenn Sie viele Daten haben, erwägen Sie den Aufbau einer Prozedur zum Einrichten der statischen Daten, die einmal pro Sitzung ausgeführt werden kann, und fügen Sie nur flüchtige Daten in
ut_setupein selbst. Dies ist besonders hilfreich beim Testen der Nur-Lese-Funktionalität. - Denken Sie daran, dass das Erstellen von Testdaten eine eigenständige Programmierübung und daher anfällig für Fehler ist.
- nutzen Sie alle Funktionen von utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountundutAssert.Eq_RefC_Querysind alles sehr nützliche Funktionen, wenn es darum geht, die Werte flüchtiger Daten abzuleiten. - Bei der Diagnose eines Testlaufs, der nicht so gelaufen ist, wie wir es erwartet haben, kann es hilfreich sein, die verwendeten Daten zu haben. Erwägen Sie also einen hohlen
ut_teardownProzedur und Löschen der Testdaten beim Start vonut_setup.
Umgang mit Legacy-Code
Als ich Garys Beitrag kommentierte, erinnerte ich mich an eine andere Sache, die Sie vielleicht nützlich finden. Steven F schrieb ulplsql als PL/SQL-Implementierung von JUnit, der Java-Avantgarde der Test-First-Bewegung. Die Techniken von TDD können jedoch auch auf große Mengen von Legacy-Code angewendet werden (in diesem Zusammenhang ist Legacy-Code ein beliebiger Satz von Programmen ohne Unit-Tests).
Das Wichtigste, was Sie beachten sollten, ist, dass Sie nicht alles sofort einem Komponententest unterziehen müssen. Beginnen Sie inkrementell. Erstellen Sie Unit-Tests für neue Dinge, Test First . Erstellen Sie Komponententests für die Bits, die Sie ändern werden, bevor Sie die Änderung anwenden, damit Sie wissen, dass sie nach der Änderung noch funktionieren.
In diesem Bereich wird viel nachgedacht, aber (unvermeidlich, wenn auch beschämend) kommt es hauptsächlich von den OO-Programmierern. Michael Feathers ist der Hauptmann. Lesen Sie seinen Artikel Working Effectively With Legacy Code . Wenn Sie es hilfreich finden, hat er anschließend ein gleichnamiges Buch geschrieben.
