Mock-Framework für JUnit Tests

[MadMetzger]

Das klingt so schonmal recht sinnvoll so. Ich hoffe, dass dir meine Hinweise oder auch Ideen weiterhelfen...

[flaite]

Ja klar.

[flaite]

Werd die Infos in unseren Unternehmensblog stellen und den Code in dem Subversion System von Google Code. Das mit dem Blog eher Ende Januar, da der welcher wirklich gut Englisch kann zur Lotussphere fährt. Upload nach Subversion vermutlich nächsten Montag.

Heute nutzt das ein Junior Entwickler, der kein Java kann, für eine Aufgabe. Werd das mal beobachten. Schreib selbst noch ein anspruchsvolleres Beispiel mit Einbindung von JFreeChart (das erzeugt Diagramme wie Balken, Kuchen, etc.).   

Fertig:
die wichtigsten Methoden der Klassen Session, AgentContext, AgentBase, Database, View, ViewColumn, DocumentCollection, Item, Name.


Die nächsten 4 Wochen:
- Deklaration der Struktur der Umgebung (Session, Database, Ansichten, Ordner, vorhandene (Profil-) Dokumente mit XML (bisher macht man das über eine einfache Factory-Klasse).
- Funktionalität von Leser- und Autorenfeldern.
- Unterstützung von Unit-Tests für Code, der von aussen auf Notes zugreift und von LS2J.
- aus Backend-Methoden wie view.getFirstDocument(), etc., database.getDocumentByUNID() wird eine Kopie des Objekts zurückgeliefert (bisher nur Objekt selbst). So können auch Speicherkonflikte simuliert werden.
- Überprüfung von recycle-Aufrufen.
- Datetime-Klasse
. Attachments in Dokumenten.

Weitere Pläne:
- RichText
- DXL
- Agent
- Mime


Noch weitere Pläne:
- API komplett
- Unterstützung einer selbstgeschriebenen @formula Engine in Java mit dem ANTLR Parser-Generator Framework.
 

[MadMetzger]

Respekt Axel... Das ist ja schon richtig umfangreich, was du da hast... Die Sache mit der @Formula-Engine würde mich persönlich aber auch mal interessieren. Gib mir mal einen Wink, wenn du damit anfangen willst, evtl habe ich dann Zeit um da was mit dran zu machen.

[flaite]

FTSearch will ich auch irgendwann machen. Mit Lucene. Damit können auch die meisten Attachments durchsucht werden. 
Der Code ist aber zu weiten Strecken echt einfach. Das war mehr tippen als programmieren. Die Views (Selektion, Spalten und Sortierung) und die Interceptoren ist wirklich das einzige, was ein bischen komplexer ist.
 
Das Projekt ist auch internationalisiert und ich werd Übersetzungstabellen für Deutsch, broken englisch und gringo-Spanisch hinterlegen. Für die Korrektur der Übersetzungen und die Anlage neuer Übersetzungstabellen sind keine Programmierkenntnisse notwendig. Aber das ist eh Standard in vielen Java-Projekten.

Die Formelsprache-Engine in Java erfordert erst mal ein bischen konzeptionelle Arbeit. Zumindest hab ich ein ANTLR Buch. Der Domiclipse Entwickler hat versucht, ANTLR auf Lotus-Script anzuwenden. Die Reaktion auf meinen entsprechenden Vorschlag auf IDEA Jam war nicht so überragend. Ist aber klar, weil eben ziemlich tief programmatisch.
http://ideajam.net/IdeaJam/P/ij.nsf/0/6021FB054E497FFA862573CA0041C196?OpenDocument

[MadMetzger]

Naja, erstmal einen Schritt nach dem anderen. Aber die Parsergeschichte interessiert mich halt, von daher hatte ich mein Interesse geäußert. Der zunächst aufwändigste Part wird dann wohl die Grammatik für den Parser sein, denke ich mal. Aber danach muss man ja auch die @Funktionen implementieren, damit man auch interpretieren kann. Ich finde das sehr interessant, obwohl ich beruflich nichts mehr mit Notes zu tun habe. Das daraus gewonnene Wissen kann man ja garantiert an anderer Stelle weiterverwenden.

[flaite]

Das zugegeben zur Zeit etwas schleppend weiterentwickelte Mockframework kann jetzt xml-Konfigurationsdateien zur Deklarierung der "Umgebung" einlesen.

Unter Umgebung verstehe ich so Sachen wie Datenbanken, Ansichten, Ordner, Dokumente.
Java-Agenten, LS2J Zeugs oder externe Javaprogramme, die mit dem Framework entwickelt und testbar gemacht werden sollen erwarten ja so etwas wie eine Umgebung.

Hier eine Beispiel-Konfigurationsdatei:

Code

<?xml version="1.0" encoding="UTF-8"?>
<declaration>
	<database title="music" path="music.nsf">
		<view name="byYear" formula="form={music}">
			<column title="year" formula="year" sort_policy="ASCENDING"
				type="int" response="false" />
			<column title="type" formula="type" />
			<column title="artist" formula="artist" />
			<column title="title" formula="title" />
		</view>
		<view name="all" formula="@all">
			<column title="form" formula="form" sort_policy="ASCENDING" />
		</view>
		<folder name="wantHear" formula="form={music}">
			<column title="artist" formula="artist"
				sort_policy="ASCENDING" />
			<column title="title" formula="title"
				sort_policy="Ascending" />
			<column title="year" formula="year" />
			<column title="type" formula="type" />
		</folder>
		
		<profile form="profile">
			<item name="aProfField">
				wert
			</item>
		</profile>

		<document form="music">
			<item name="year" type="NUMBERS">1835</item>
			<item name="artist">Robert Schumann</item>
			<item name="type" sep=",">Clasic, Romantic</item>
			<item name="title">Von fremden Ländern und Menschen</item>
		</document>

		<document form="music">
			<item name="year" type="NUMBERS">1977</item>
			<item name="artist">Joy Division</item>
			<item name="type" sep=",">Pop</item>
			<item name="title">Control</item>
		</document>





	</database>

</declaration>

Damit werden dann in der Umgebung die im xml deklarierten Datenbank(en), die Ansichten, die Profildokumente, die Ordner und die Dokumente angelegt.

Hier ist Testcode, der die obige xml einliest:

Code

		MockFactory fac = MockFactory.getInstanceXmlDecl("mockfactory.xml");
		Session s = fac.getSession();
		Database db = s.getDatabase("", "music.nsf");
		View vw = db.getView("byYear");
		;
		System.out.println(vw.prettyPrint());

Hier ist das Ergebnis vom System.out des Testcodes:

Code

Datenbank=music(music.nsf)
Ansicht=byYear, Selektionsformel=form={music}

year|type            |artist         |title                           |
____|________________|_______________|________________________________|
1835|Clasic, Romantic|Robert Schumann|Von fremden Ländern und Menschen|
____|________________|_______________|________________________________|
1977|Pop             |Joy Division   |Control                         |
____|________________|_______________|________________________________|

Sobald sich das xml stabilisiert, werd ich dafür ein xml-Schema schreiben. So kann leichter validiert werden, ob die Eingaben des Benutzers im xml ok sind. 
Xml ist natürlich ein ziemlich geschwätziges Format, aber man kann da prima mit copy und paste arbeiten und es ist eben ziemlich selbsterklärend.
Ich denke auch darüber nach DXL einlesen zu können, das kommt aber später.

[m3]

Falls noch nicht bekannt:

Using easymock for disconnected Domino Java testing

For his testing he would rather not connect to the Domino server all the time, but instead mock up objects to make sure that his other code works correctly. Enter EasyMock, which is a JAR file which you can include in any project that basically pretends to be whatever object you want it to be.

http://www.11tmr.com/11tmr.nsf/d6plinks/MWHE-7BKDJC

[flaite]

Das ist natürlich auch eine Lösung.
Je mehr Logik auf Domino selbst zugreift, desto löchriger und anstrengender wird dieser Ansatz mit JMock.
Werd noch diese Woche hochladen.
Bin noch ziemlich an kämpfen mit einer Ajax Anwendung, die budgetonisch aus dem Ruder gelaufen ist und einem Java-Kurs, den ich hier intern gebe.

[StephanKoo]

Moin,

kann man das Ergebnis nutzen? Der Thread hörte irgendwie so plötzlich auf.

Danke
   Stephan Koops

[klaussal]

Das ist 6 Jahre her.....

[StephanKoo]

ja, ich weiß, aber vielleicht ist das Ergebnis ja trotzdem nutzbar.

[flaite]

Hab den code nicht mehr. Habs für ein Projekt genutzt. War aber dafür overkill. Danach hab ich afaik kein einziges Notes Projekt mehr gemacht.
Ich glaub, dass man sowas heute nicht mehr braucht. Hast Du mal versucht NotesJava Klassen mit mockito zu mocken?