In Junit muss die Klasse von Junit gemanaged werden. D.h. von Junit gestartet.
Ein Notes Agent benötigt um überhaupt laufen zu können Notes als Container/Runtime.
Und Junit ist nicht in Notes integriert.
Man kann höchstens in der setUp Methode des Junit-TestCases eine Verbindung zu NotesDatabase aufnehmen und den Agenten starten. Damit testet man aber nur die Main Methode. Ok. Ich gebe zu, dass dies auch die einzige sinnvolle public-Methode eines Notes Agenten ist. Aber die gibt void zurück. Und ein Notes Agent ist von aussen quasi stateless. Wenn ich mit Junit einen Agenten starte und dann nach dem Test ein Property überprüfen will, dann geht das nicht. Weil wenn Main retuniert ist, ist die Agenteninstanz quasi auch tod. Man könnte höchstens nach dem Laufen des Agenten bestimmte Dokument-Felder oder sonstiges überprüfen, um so zu verifizieren, dass der Agent gemacht hat was er sollte. Aber dann ist das nächste Problem: Wie stelle ich zur Wiederholung des Tests wieder das Ergebnis vor dem Lauf des Agenten her. Natürlich ist das *irgendwie* möglich. Aber es ist eben eine Menge Extra-Arbeit.
In einem Junit-Integrationstest gegen eine Relationale Datenbank zu erstellen, benötige ich einfach nur ein ant-build.xml target mit sql-Task, der die entsprechenden drop-tables, create tables und inserts durchführt. Und dann gibt es da noch fertige Erweiterungen, falls dies einem zu lange dauert (bei mir nicht der Fall).
Ich benutze Eclipse zunehmend nicht mehr als reiner Editor mit Code Completion, sondern um ein Ding, womit ich - in Verbindung mit so Sachen wie Junit und Ant - viele weitere Teile des Projektzyklus automatisieren kann (build, Integrationstest, Last-Test). Und ich find das spannend.
Schwieriges Junit Testing war auch immer ein Argument von POJO-Freunden gegenüber EJBs. Wobei es da jetzt bei EJB besserde Möglichkeiten gibt (kenn ich aber noch nicht).