ReadMore

Seit letzter Woche habe ich SimpleTest im Einsatz und bin davon ziemlich begeistert. Das Framework bietet alles was man von einem konventionellen Unit-Testframework her kennt, wie diverse Assertion-Methoden oder Gruppierung von Testfällen zu Testsuiten. Daneben gibt es aber noch eine ganze Reihe von coolen Erweiterungen:

• Es gibt einige vordefinierte Test-Reports, welche den Erfolg (oder Misserfolg) der Tests anzeigen. Wenn einem diese nicht genügend kann man diese (dank OO) ganz einfach erweitern. So habe ich meinen “persönlichen” Testreporter geschrieben, welcher mir neben den Details zu den Fehlern auch die Details zu den erfolgreichen Tests beschreibt (dazu muss man nur die Methode paintPass() überschreiben), das Resultat ist in obigem Bild ersichtlich.
• Man kann auch sogenannte Web-Tests machen, d.h. man kann das Browserverhalten simulieren und so beispielweise automatisiert ein Formular ausfüllen und abschicken lassen, anschliessend dann das Ergebnis prüfen.
• Das erzeugen von Mock-Objekten ist kinderleicht, das Framework bietet eine einfache Methode um eine “leere” Hülle eines Objekts zu generieren (z.B. einer Datenbankverbindung)

Das Tutorial führt einem durch die ersten Schritte, die API gibt den vollständigen Überblick. Durch die verschiedenen Reporter kann das gleiche Skript auch gebraucht werden um in einem automatisierten Build zu laufen, so wie man es z.B. von JUnit kennt.

Ich habe momentan alle meine Testfiles in einem Verzeichnis und habe mir deshalb ein simples Skript geschrieben, welche alle Tests ausführt:

[Pastie-Link]

Um jedes einzelne File jedoch immer noch separat ausführen zu können, include ich autorun.php nur genau dann, wenn ich das File direkt anspreche:

if (count(get_included_files()) == 1)
{
    require_once("includes/simpletest/autorun.php");
}

Ich kann das Framework also nur empfehlen!

I really like unit testing, and nowadays there is an helping framework for almost every environment and/or programming language. For PL/SQL this is utPLSQL, which consists of a bunch of packages that you need to put on your database and then you should be good to test your could. You should.

I just spent some hours debugging my test code, so I want to share this with you, maybe I can save someone out there some time.

My setting

• Schema A: utPLSQL package
• Schema B: package XY (code to test), package UT_XY (test code)

I have two schemas A and B. In schema A utPLSQL is installed, and in B is the code to test. It is recommended to have your code to test and your test code in the same schema.

The following script is used to run the tests:

 begin
   for c in (select object_name,owner
               from all_objects
              where object_name like 'UT\_%' escape '\'
                and object_type ='PACKAGE')
   loop
     begin
     utPLSQL.test(
       package_in => substr(c.object_name,4),
       prefix_in => 'UT_',
       owner_in => c.owner
     );
   exception
     -- in case of a faulty unittest continue with the others.
     when others then
       null;
   end;
   end loop;
 end;
 /

But I kept getting the error:

 Program named "XY" does not exist.

So I thought that somehow the schema A does not “see” the packages in the schema B and created public synonyms. Unfortunately this didn’t help. Then I tried to move the “UT_” package to schema A, which worked, but now I got an error that the code to test and the test code are in different schemas.

There must be something obvious I’m missing!

And there it was: A had not “execute” grant on the packages in B.

  grant execute on b.xy to A;

Now everything just worked fine.