PL/SQL Unit testing

-

Datenbank unit testing best practise:

  • Eine private Datenbank Instanz für jeden Developer. Beim Entwickeln von Tests für Datenbanken ist sehr wichtig, dass der Zustand von dem Datenbank Schema und Daten während der Entwicklung sich nicht verändert. Deswegen, in Projekten mit mehreren Entwicklern, sollte jeder Entwickler in eigener privater Instanz arbeiten, um Konflikten mit anderen Entwicklern oder Programmen zu vermeiden.
  • Tests müssen unabhängig von Resultaten der anderen Tests sein. Am einfachsten kann man das erreichen, indem man vor jedem Test die Datenbank in initialen Zustand versetzt. Als mögliche Lösung kann man nach jedem Test die Datenbank Schema vollständig aufräumen, oder einfach keine Test Daten und Ergebnisse speichern (Rollback nach jedem Test).
  • Eine Cleanup Funktion. Es ist oft nötig oder unvermeidlich (automatisches commit beim DDL Operationen in Oracle), dass während der Test-Ausführung, Daten in der Datenbank gespeichert werden. Man sollte für diese Fälle eine Cleanup Funktion entwickeln, die das ganze Schema in Initialzustand versetzt, zum Beispiel durch das Einspielen von DB Dump, oder vollständiges Aufräumen der Inhalte aller Tabellen.
  • Kleine Datasets. Für die meisten Unit-Tests ist das vollständige Datenbank Inhalt nicht erforderlich. Stattdessen sollte man womöglich nur kleine, spezifische Datasets für jeden Test erstellen, was die Fehleranalyse erleichtert und einzelnen Tests unabhängig voneinander macht.
  • Gemeinsame Datasets. Viele Tests verwenden ähnliche Initialdaten, um die Entwicklung von solchen Tests zu vereinfachen, sollte man gemeinsame Datasets definieren, die von unterschiedlichen Tests wiederverwendet werden können. Die gemeinsame Datasets können auch vor der Ausführung von Test-Suits (die auf gemeinsamen Daten basieren), direkt in die Datenbank gespeichert werden, um die Test-Initialisierung zu verkürzen. Nach der Test-Suite Ausführung muss die Cleanup Funktion ausgeführt werden.
Weitere Links:
Präsentation von Steven Feuerstein über UnitTesting von PL/SQL

Frameworks zum Unit-Testing von PL/SQL Programmen.

NameVersionLicenceTest styleLink
utPLSQL2.2GPLStored ProceduresURL
Quest code tester?proprietarydeclarativeURL
PL/Unit?proprietaryPL/SQL packagesURL
PLUTO – PL/SQL Unit Testing for Oracle49Artistic License/GPLPL/SQL classesURL
ruby-plsql-spec0.2.1freeRuby DSLURL
DBFit1.1GPLfunctional specifikationURL
DBUnit2.4.8Lesser GPLJava/XMLURL
SQLDeveloper3.0proprietaryWizards, SQLURL


Quelle: http://www.vilinski.de/tag/plsql

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

trunc(sysdate) - nette Spiele mit dem Datum

-
Über die trunc-date Funktion läßt sich ausgehend von einem Datumswert sehr einfach ein abgeleiteter Datumswert ermittelt: bspw. der Jahres-, Quartals-, Monats- oder Wochenanfang. Die 11g Doku erläutert dies an zwei Stellen: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions209.htm#SQLRF06151 bzw. http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions242.htm#sthref2718 So liefert select trunc(to_date('06.02.2011'),'q') from dual; das DATUM des Quartalsersten (im Bsp. den 01.01.2011). Wichtig ist, dass trunc immer ein Datum zurückliefert, keinen String. Einige Beispiele anhand des 20.Feb 2011 (ein Sonntag in der 07 KW in 2011): select trunc(to_date('20.02.2011'),'d') from dual; select trunc(to_date('20.02.2011'),'dd') from dual; select trunc(to_date('20.02.2011'),'ddd') from dual; select trunc(to_date('20.02.2011'),'mm') from dual; select trunc(to_date('20.02.2011&
Mehr anzeigen

Zufallszahlen und -text generieren - DBMS_RANDOM

-
Um für Testzwecke etc. "zufällige" Zahlen / Strings zu erzeugen, gibt es in Oracle die Funktion dbms_random . In Verbindung mit connect by kann so sehr einfach eine beliebige Menge an Zeilen mit Zufallswerten erzeugt werden: SELECT dbms_random.value(1,1000) Z       , dbms_random.string('a',20) Txt   FROM DUAL CONNECT BY level < 101; * DBMS_RANDOM.VALUE(low, high)   + low -> untere Grenze   + high -> obere Grenze * DBMS_RANDOM.STRING(opt, len)   + opt -> Definiert, was für ein String erzeugt wird   + len -> Länge des String   + Details zu opt: 'u', 'U' - returning string in uppercase alpha characters 'l', 'L' - returning string in lowercase alpha characters 'a', 'A
Mehr anzeigen

Laufzeiten umrechnen, Sekundenangaben lesbar darstellen

-
Hintergrund: Laufzeiten von diversen Prozessen werden (Tool-)intern in Sekunden gemessen und meist auch so dargestellt. Für Weiterberechnungen und Auswertungen ist das Ideal. Der Lesbarkeit für den geneigten Nutzer nur bedingt dienlich. Wer erkennt schon auf den ersten Blick, wie lange 14.738sec sind? Lang halt. Lösungsansätze: Für die Lesbarkeit, kann man diese Werte natürlich entsprechend umrechnen. Aber wie? 14.738sec vermutlich am Besten in Stunden: 14.738/60/60 = 4,0939 Stunden -> Aha. Aber was ist mit 249sec? 249/60/60 = 0,069 Stunden - Wie lang bitte sind 0,069Std? 249sec also besser in Minuten umrechnen: 249/60 = 4,15 Min -> schon besser Also per CASE-Statement die unterschiedliche großen Sekundenangaben passend umrechnen? Nicht schön und umständlich. Netterweise bietet Oracle mit der to_date()-Funktion auch den Formatstring 'sssss' (5x kleines 's'). Per to_char( to_date(14768,'sssss') ,'HH24:MI:SS') werden aus den Sekunden
Mehr anzeigen