Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Mock-Framework für JUnit Tests

<< < (4/7) > >>

flaite:
... in der attachten html-Datei.
hellgrün -> implementiert.
rotbraun -> nicht implementiert.

Manche der nicht implementierten Methoden sind recht obskur oder betreffen das UI (z.B. setShowTwistie() in der Klasse ViewColumn).
Die Datei ist generiert mit einem zusäztlichen Hilfs-Projekt, einfach mit Java-Reflection.

Neue Features können noch recht schnell hinzugefügt werden
- folders
- "Mail"-Methoden wie document.send() -> mit interceptoren, die die vom Agenten "versendeten" Mails in eine Art Queue schreiben, so dass sie etwa durch Unit-Tests überprüfbar sind.

Auf ein interessantes Problem bin ich gestossen:
Unterschiedlicher State von Dokumenten. Wenn ich den state eines vorher gespeicherten Dokuments ändere. (Etwa durch doc.replaceItemValue(fieldName, value), sind diese Werte ja nicht im Notes-Dokument abgebildet, wenn ich es über das Backend neu lade (etwa per database.getDocumentByUNID) bevor ich die State-Änderungen per doc.save() ins Backend schreibe. Da weiss ich noch nicht richtig, wie ich das abbilde. Sollte jemand das Problem verstehen und eine Idee haben, immer her damit. Vielleicht bietet es sich an, couchDB - an dem ja der wieder-IBM Mitarbeiter Damien Katz weiterarbeitet - als eine Art Persistenzmanager zu verwenden. Muß das aber noch prüfen. Ist jetzt aber sowieso nicht top-Prio.

Gruß Axel

MadMetzger:
Hm... Ich habe gerade dein Posting gelesen. Nach wie vor finde ich das ein gutes Projekt und bin doch sehr überrascht, wie stark man Notes doch "mocken" kann.

Zu deiner Frage:
Kann man dein Problem nicht evtl über eine Art Caching-Mechanismus und Proxies lösen? Also die Dokumente liegen in einem zentralen Cache, aus dem sie bei den verschiedenen Lade-Methoden als Proxy ausgeliefert werden. Beim Speichern wird dann der Proxy an den Cache gegeben, wo er versucht die neuen Daten ins Original zurückzuschreiben. Nur so als Idee. An der Stelle hast du dann auch die Chance Replizierkonflikte zu erzeugen, wenn nämlich zwei zur gleichen Zeit geholte Dokumente zu unterschiedlichen Zeiten zurückschreiben wollen. Was hälst du von dem Vorschlag?

EDIT: Noch eine weitere Idee, zur Ansiedlung des Dokumenten-Cache: Der sollte vielleicht je Notesdatenbank verfügbar sein.

flaite:
Mit Proxy hat das glaub ich nichts zu tun.

Durch die Persistenz in Notes, können unterschiedliche Versionen von Document-Objekten mit der gleichen DocUnid existieren.

--- Code: ---Document docNew = db.createDocument();
docNew.replaceItemValue("form", "form1");
docNew.save();
Document docFromPersistedMem = db.getDocumentByUNID(docNew.UniversalID);
docNew.replaceItemValue("land", "Germany");

--- Ende Code ---

docNew und docFromPerstistedMem haben die gleiche UniversalID.
Das Objekt docNew hat am Ende des scripts ein Feld "land".
Das Objekt docFromPersistedMem hat dieses Feld dagegen nicht.
Erst durch ein docNew.save() würden beide Versionen wieder synchronisiert.

Das ist durch mein MockFramework zur Zeit schwer abzubilden, da es gar keinen persistenten Speicher hat. Die Dokumente sind rein in-Memory, dh. sie liegen in Database in (mehreren) Maps.

Zur Abbildung wäre es vermutlich am einfachsten, wenn ich eine Persistenzschicht einziehen würde. Eine Persistenzschicht zu simmulieren, dürfte auch machbar sein.
Allerdings bewege ich mich hier schon in Corner-Cases, die nicht Bestandteil der 1. Version sind.

MadMetzger:
Stimmt, richtige Proxies sind das nicht so wirklich. Es sind ja keine Stellvertreter in dem Sinne.

Aber vom Prinzip würde ich nur Kopien ausliefern und die dann auf die Originale zurückschreiben.

flaite:
Das stimmt vermutlich mit den Kopien. Nur muss ich die eben als tiefe Kopien ausliefern.
Ein Document enthält Item Objekte. Da können nicht einfach die Referenzen kopiert werden, sondern es müssen eben echte Kopien erstellt werden. In den Items sind wiederum String-, Number- und Datums-Objekte. Da können immer dann Referenzen kopiert werden, wenn die Klasse inmutable ist.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete