Ab und zuhöre ich mehr oder weniger zufällig, dass der eine oder andere SASUnit benutzt. Über Erfahrungsberichte würde ich mich sehr freuen. Auch ein "Hallo, ich nutze es" wäre besser als nichts.

Unterstützung für unterschiedliche Sprachen (National Language Support, NLS) wurde hinzugefügt, siehe englischsprachige Version dieser Seite.

• Die Dokumentation aller nicht-internen Makros wurde auf englisch übersetzt. (Interne Makros beginnen mit _sasunit_.)
• Der komplette Testbericht ist nun mehrsprachig, derzeit deutsch und englisch. Gesteuert wird dies durch einen Parameter in reportSASUnit.
• Alle Beispielprogramme im Ordner /example wurden komplett auf englisch übersetzt.

assertReport kann nun für den Vergleich zweier Reports die Reports direkt in HTML-Frames übereinander darstellen.

Schließlich gab es noch einige Fehlerbereinigungen.

Download Komplettversion
Download Delta 0.902 zu 0.904

%assertColumns wurde komplett überarbeitet. Es gibt jetzt einen Parameter i_allow, der steuert, wie streng die Prüfung durchgeführt werden soll. Siehe hierzu die Dokumentation für %assertColumns, das auf PROC REPORT beruht, oder direkt in der SAS-Online-Dokumentation zu den Return Codes von PROC REPORT.

Im Unterverzeichnis examples findet sich jetzt ein Beispiel für den Vergleich von Ergebnissen, die mit Microsoft Excel und SAS gerechnet wurden.

Download Komplettversion
Download Delta 0.901 zu 0.902

%assertEquals wurde verbessert, es kann jetzt beim Vergleich von erwartetem und tatsächlichem Wert besser mit unterschiedlichen Datentypen umgehen. Dazu wurden einige kleinere Verbesserungen an der Dokumentation vorgenommen.
Download Komplettversion
Download Delta 0.9 zu 0.901

Hier eine Kurzanleitung für die Erweiterung von sasunit um neue Zusicherungen, also neue %assert...-Makros.

Die Aufgabe besteht aus folgenden Schritten:

1. Neues %assert…-Makro schreiben, am besten eine geeignete Vorlage wählen, ich wähle hier %assertColumns als Vorlage.
   • die ersten Makroanweisungen sichern die Call-Reihenfolge der Makros ab, sie kann man einfach so übernehmen.
   • %_sasunit_asserts aufrufen (vorher Rückgabevariablen lokal deklarieren), dabei übergeben:
     • den Namen des neuen %assert…-Makros
     • den erwarteten Wert, wie er in der Datenbank stehen soll und wie ihn später das Makro für die Berichtserstellung verwenden soll (z.B. ein Textstring „BETWEEN 0 AND 1“ o.ä.)
     • den tatsächlichen Wert (z.B. „0.5“)
     • die restlichen vier Parameter einfach übernehmen

     Danach sind folgende Makrovariablen verfügbar:

     • g_scnid: Nummer des laufenden Testszenarios
     • l_casid: Nummer des laufenden Testfalls innerhalb des Testszenarios, beginnend bei 1 pro Szenario
     • l_tstid: Nummer der laufenden Prüfung innerhalb des Testfalls, beginnend bei 1 pro Testfall

     Diese Makrovariablen werden ggfs. im nächsten Schritt gebraucht, um Dateien zu benennen, die in die Testdatenbank geschrieben werden sollen, damit diese später bei der Berichtserstellung identifiziert werden können.

   • Prüfung durchführen und das Ergebnis in der Spalte tst_res der Tabelle target.tst aktualisieren, siehe SQL unter „Ergebnis aktualisieren“. Folgende Ausprägungen sind möglich:
     • 0 … OK (grün)
     • 1 … Fehler (rot)
     • 2 … manuell nachprüfen (leer/weiß)
   • Falls es gewünscht wird, dass Dateien in die Testdatenbank geschrieben werden, um sie später im Bericht zu verlinken, sollte das nun erfolgen. Im Beispiel werden drei Dateien geschrieben: ein Katalogeintrag mit einem ODS-Bericht sowie zwei SAS-Tabellen. Es ist auf korrekte Benennung der Dateien zu achten: als Libref wird testout verwendet bzw. als Pfad &g_testout. Die Dateien müssen im Namen die drei Ids g_scnid, l_casid und l_tstid enthalten und ansonsten einen Namen, der sie von allen anderen Objekten in der Testdatenbank unterscheidet, am besten daher auch den Namen des assert…-Makros mit aufnehmen.
2. Der folgende Schritt ist optional: Für relativ komplexe Fälle (wie assertColumns) wird ein spezielles Rendering von Objekten für den zu erstellenden Bericht benötigt, unter anderem deshalb, weil es angedacht ist, später auch einmal in andere Formate zu rendern. Bei %assertColumsn ist es so, dass bei dessen Aufruf zunächst SAS-Tabellen und Kataloge geschrieben werden, die dann hier noch in HTML umgewandelt werden müssen. Sollte das nötig sein, kann man einen eigenen Makro %_sasunit_report…HTML schreiben nach dem Vorbild von %_sasunit_reportCmpHTML und muss dann auch in %reportSASUnit unter „pro Testfall“ einen neuen Abschnitt für dessen Aufruf einfügen.
3. Falls es für den Testbericht genügt, den Inhalt, der oben mit %_sasunit_asserts für den erwarteten und den tatsächlichen Wert übergeben wurde, darzustellen, ist man jetzt mit der Programmierung fertig. Andernfalls wird man in das Programm %_sasunit_reportDetailHTML, das das Rendering des Detailberichts aller Asserts eines Testfalls übernimmt, unter „SELECT(upcase(tst_type));“ einen Abschnitt einfügen, der spezielles Rendering vornimmt, siehe Beispiel für ASSERTCOLUMNS, wo entsprechende Hyperlinks auf die in der Testdatenbank liegenden Objekte eingefügt werden.
4. Zum Schluss sollte man das neue Assert in _sasunit_doc dokumentieren.

Bitte schicken Sie mir geänderte Versionen von sasunit zu, damit ich die Aufnahme in ein Update prüfen kann.