Ausblick 2013: Xpert.ivy Applikationsentwicklung und Extensions

Das Jahr neigt sich dem Ende zu und ich will die Gelegenheit nutzen, um mich bei allen meinen Lesern zu bedanken. Es waren tolle erste Wochen als Xpert.ivy Blogger und ich hoffe es hat Ihnen genauso viel Spass gemacht wie mir.

Bevor ich mich für dieses Jahr verabschiede, möchte ich Ihnen einen kurzen Ausblick auf 2013 geben und was Sie auf xpertivyhacker.ch erwarten können.

Ein Fokus wird die Applikationsentwicklung mit Xpert.ivy Rothorn und JSF/PrimeFaces sein. Ziel ist es an Hand praktischer Beispiele zu zeigen, wie man Applikationen und wiederverwendbare Komponenten mit dem neuen Xpert.ivy Release entwickelt und testet.

Ein weiteres Projekt das ich starten werde ist die Entwicklung von Xpert.ivy Extensions. Mehr will ich dazu aber noch nicht verraten. Damit Sie den Start und News über dieses Projekt nicht verpassen, können Sie sich hier für den Xpert.ivy Extensions Newsletter anmelden.

Als kleines Weihnachtsgeschenk an Sie können Sie mir Ihre Wünsche für Blog-Themen und Xpert.ivy Extensions in den Kommentaren oder auf Twitter mitteilen und mit etwas Glück werde ich Ihrem Wunsch nächstes Jahr nachkommen.

Ich werde nun in die Weihnachts- und Neujahrspause gehen und im Januar wieder voll durchstarteten.

In diesem Sinne wünsche Ihnen und Ihrer Familie frohe Festtage und einen guten Rutsch ins neue Jahr!
Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

Rothorn Sprint 11 Review Meeting

Heute haben die Jungs vom IvyTeam die Resultate des Sprint 11 im Review Meeting gezeigt, der unter dem Motto System DB and Library Updates stand. Es ist ein Sprint voller technischer Updates.
  • Java 7
  • Tomcat 7
  • Ivy spezifischer Editor wird für SVN/Local History Einträge geöffnet
  • JPA 2.0 (Hibernate 4.1)
  • 64 bit IDs in der Datenbank
Das Update auf Tomcat 7 hat positive Auswirkungen auf PrimePush. Nun können, falls es der Browser unterstützt, native Websockets verwendet werden. Bei den bisherigen Rothorn Sprint Inkrements wurde Tomcat 6 verwendet und deshalb nur ein Fallback auf Comet/Long Polling von PrimePush gemacht.

Mein persönliches Highlight ist das öffnen von Ivy spezifischen Editoren für Einträge die man aus der SVN bzw. Local History öffnet. Dies ist vor allem für das Mergen von Prozessen praktisch, da man nun visuell sehen kann wo die Unterschiede sind.

Die 64 bit IDs haben Auswirkungen auf die Public API. Da IDs nun vom Typ Long und nicht mehr Integer sind, wurden Methoden  wie z.B. ITask.getIdentifier() deprecated. Neu gibt es dafür z.B. ITask.getId(), die einen Long zurück gibt. Während die deprecated Methoden noch funktionieren, sollten man den Code updaten um Probleme bei einem Integer-Overflow zu vermeiden. Mehr dazu findet man in den Migration-Notes.

Eine Liste aller erledigten Punkte findet man auf dem ivyTeam Blog.
Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

Quickfix für Html User Dialoge

Eines meiner neuen Lieblings-Features in Xpert.ivy Rothorn ist der Quickfix für die Html User Dialoge. Wenn ein Attribut, Event oder eine Methode fehlt, kann man per CTRL+1 ein Kontextmenü öffnen um das fehlende Attribut, Event oder Methode zu erstellen.

Ich habe ein Video erstellt das dieses Feature demonstriert.


Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

IvyScript und null

IvyScript ist die Scriptsprache die in Ivy auf Prozesselementen verwendet wird. Während IvyScript Java sehr ähnelt, gibt es subtile Unterschiede. Einer dieser Unterschiede ist das null Handling.

Schauen wir uns das erste Beispiel an.

Code Snippet 1: Was wird es ausgeben?

Wäre dies hier Java, wäre in.string == null true. Doch in IvyScript wird diese Bedingung false sein. Der Grund dafür ist das sogenannte Auto-Initialisieren von Variablen die null sind. Wenn auf eine Variable die null ist zugegriffen wird, dann wird diese mit einem Standard Wert initialisiert. Ein String der null ist, ist danach "", eine Number ist 0 und ein Boolean ist false.

Bei Ivy Datenklassen wird eine neue Instanz erstellt. Java-Objekte müssen es einen Default Konstruktor haben, sonst funktioniert die Auto-Initialisierung nicht.

Doch was ist wenn man das nicht will? Dazu kann man einfach # vor das Attribut schreiben.

Code Snippet 2: Variable nicht Auto-Initialisieren

Nun wir die Bedingung true sein.

Was ist, wenn man ein Objekt erhält, dass man nicht selber unter Kontrolle hat? Es könnte also sein, dass es schon Auto-Initialisiert ist. Das Objekt ist danach zwar nicht mehr null, aber trotzdem ist es nicht richtig initialisiert. Ein Beispiel ist, wenn ein Objekt per in.meinObjekt an einen Callable als Parameter mitgegeben wird. Das Objekt ist danach Auto-Initialisiert und in.#meinObjekt wird nicht mehr null sein.

Um dieses Problem zu lösen bietet IvyScript is initialized an.

Code Snippet 3: is initialized

Auf der ersten Zeile wird in.string Auto-Initialisiert. Würde man nun mit in.#string != null die Abfrage machen, so würde dies true zurück geben. Um zu testen, ob ein Objekt nicht Auto-Initialisiert wurde, kann man is initialized verwenden. In diesem Fall wird hier not initialized geloggt.
Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

Xpert.ivy Html User Dialoge mit Selenium testen

Wer kennt das nicht? Schnell etwas fixen, Engine starten und kurz darüber schauen um sicher zu gehen, dass das gefixte auch so funktioniert wie man es angedacht hat und nichts anderes kaputt ging. Der Schock kommt jedoch meistens kurz nachdem man das Ganze auf dem Kundensystem deployt hat und sich der Kunde über neue Fehler beschwert, die seit dem Update auftauchen.

Was ist passiert? Die Unit- und Integrationstests waren alle grün. Der Fix funktioniert einwandfrei. Doch ein Button auf der Maske auf der man etwas gefixt hat macht nichts mehr! Kurz Debuggen und tatsächlich: Ein Event wurde umbenennt, auf das der actionListener des Button gemappt war.

GUI Testing Tools können Ihnen helfen, solche Fehler schon während dem Entwickeln zu finden und zu beheben.

In diesem Tutorial zeige ich, wie man mit Selenium, dem PageObject und Business Rule-User Interface Workflow-Technical Activity Pattern wartbare Html User Dialoge Tests schreibt.

Selenium ist eine GUI Testing Bibliothek, mit der ein JUnit-Test einen Browser Steuern kann um z.B. eine Seite zu öffnen, Buttons zu drücken und Text einzugeben. Darüber hinaus bietet Selenium Funktionen an, um Elemente und deren Inhalt aus einer Seite auszulesen. Selenium bedient sich sogenannter WebDrivers um Browser wie z.B. Firefox oder Chrome fernzusteuern.

Beispiel Projekte

Ich habe ein Ivy und ein Java Projekt als Beispiel per SVN bereit gestellt.
Das Java Projekt hat die Selenium Bibliothek eingebunden. Die Jars sind alle von selenium-java.2.27.0.zip.

Damit das Beispiel läuft, müssen Chrome und der Selenium ChromeDriver (download) installiert sein. ChromeDriver erlaubt es Selenium Chrome fernzusteuern.

Wenn Sie einen anderen Browser wie z.B. Firefox oder Internet  Explorer zum testen verwenden wollen, müssen Sie einen anderen WebDriver installieren. Beachten Sie dazu die Anleitung des entsprechenden WebDriver. Des Weiteren muss bei den Tests eine andere WebDriver Klasse verwendet werden.

Um ChromeDriver Selenium zugänglich zu machen, muss das Verzeichnis in dem der ChromeDriver liegt zu der Umgebungsvariable PATH hinzugefügt werden. Zum verifizieren ob er richtig installiert ist, geben Sie über die Command Line chromedriver ein. Wenn Started ChromeDriver  zu sehen ist, ist ChromeDriver richtig installiert.

Starten Sie nun die Xpert.ivy Engine und den JUnit-Test MyApplicationTest.java im MyApplicationsTests Projekt. Chrome öffnet sich und die definierten Tests werden abgespielt.

Business Rule-User Interface Workflow-Technical Activity Pattern und Page Objects

Ein grosses Problem bei GUI-Tests ist die Wartbarkeit. Jedes mal wenn sich eine Maske ändert, so müssen sich je nach Test-Architektur auch alle Tests die etwas auf dieser Maske machen, angepasst werden.

Gojko Adzic hat in diesem Blog Post einen interessanten Ansatz um GUI-Tests wartbar zu machen. Er bricht dazu einen GUI-Test in 3 Teile auf.
  • Business Rule - Was soll getestet werden? Beispiel: Einloggen mit ungültigem Benutzernamen/Passwort zeigt Fehler an.
  • User Interface Workflow - Was muss der Benutzer machen damit die Business Rule eintrifft? Beispiel: Applikation öffnen, falsche Benutzername/Passwort Kombination eingeben, Fehler wird angezeigt
  • Technical Activity - Wie wird dies Technisch gelöst? Beispiel: Seite unter http://xyz öffnen, falsche Benutzername/Passwort Kombination ins Feld Benutzername/Passwort eingeben, Login Button klicken usw.
Code Snippet 1: Business Rule und User Interface Workflow

In Code Snippet 1 sieht man die ersten beide Teile. Der Methodenname ist die Business Rule: Mit ungültigen Benutzername/Passwort einloggen zeigt einen Fehler an.

Die Implementation des Tests ist der User Interface Workflow. Hier sieht man grob, wie der Test ablaufen muss. Die Methoden die hier aufgerufen werden, repräsentieren den dritten Teil, die Technical Activity.

Code Snippet 2: Technical Activity

In der Technical Activity wird nun die technische Implementation des Tests gemacht. Hier kommen sogenannte Page Objects zum Einsatz, die das was (Login Seite öffnen) vom wie (Selenium Code: gehe zu Url http://xyz) abstrahieren.

D.h. wenn wir etwas am GUI verändern, so müssen wir mit grosser Wahrscheinlichkeit nichts am Test selber ändern, sondern nur in den Page Objects.

Eine interessante Eigenschaft von Page Objects ist, dass Sie andere Page Objects zurück geben können.

Code Snippet 3: Page Object

Hier erhalten wir ein ApplicationPage Objekt zurück, als die nächste Seite, nachdem wir uns mit gültigen Credentials angemeldet haben. Dieses Page Objekt können wir im weiteren Testverlauf verwenden.

Code Snippet 4: Page Object und assert

Zusammen mit der ApplicationPage machen wir in einer Technical Activity nun eine Assertion. Wir holen uns von der ApplicationPage das Greeting und prüfen, ob diese Welcome Hans Peter beinhaltet.

Wie in diesem Beispiel zu sehen ist, abstrahieren die Page Objects den Zugriff auf das Html der Seite. Dies ist wichtig für die Wartbarkeit. Ändert sich etwas an dem GUI, so muss meistens nur in dem Page Object etwas angepasst werden. Des Weiteren können diese Page Objects gut  in anderen Tests wiederverwendet werden, was wiederum die Wartbarkeit steigert.

Als Kontrast dazu: Stellen Sie sich vor, man hätte den ganzen Selenium Code direkt in die Tests geschrieben. Wenn nur die ID eines Feldes ändert, so müsste man das in jedem Test anpassen. Mit dem Page Object braucht man dies nur an 1 Stelle zu tun.

Selenium, PrimeFaces und IDs

Um Elemente wie z.B. Input-Textfelder zu finden, bietet der WebDriver die findElement Methode an, die ein By Objekt als Parameter entgegen nimmt. Mit By kann man z.B. per ID oder CSS-Selektor nach einem Element auf der Seite suchen.

In PrimeFaces kann man zwar IDs definieren, jedoch wird vor diese ID immer noch ein Zusatz vorangestellt. D.h. wenn man By.id() nach diesem Element sucht, bekommt man nichts zurück. In diesem Fall kann By.cssSelector() benutzt werden.

Code Snippet 5: By.cssSelector

Das $ vor dem = bedeutet, dass die id mit username enden muss. Vorsicht: Befinden sich mehrere input Elemente die mit username enden auf der Seite, muss man einen anderen Weg finden.

AJAX und WebDriverWait

Html User Dialoge bzw. PrimeFaces setzen auf JavaScript und AJAX. Da Selenium nicht wissen kann, wann ein AJAX Request fertig ist, gibt es die Utiltity Klasse WebDriverWait.

Code Snippet 6: WebDriverWait

Diese Klasse kann dazu eingesetzt werden, um auf einen AJAX Request für eine gewisse Zeit zu warten, bis das Element, dass nach dem AJAX Request erscheinen sollte, auf der Seite ist. Falls man dies nicht tut, wird der findElement Aufruf immer fehlschlagen. Wenn der AJAX Request länger als das Timeout dauert oder das Element nicht erscheint, wird eine Exception geworfen.

Fazit

In diesem Tutorial bin ich bewusst nicht tiefer auf die Selenium API eingegangen, da es mir wichtiger ist, dass GUI-Tests sauber und wartbar geschrieben werden. Mit dem Business Rule-User Interface Workflow-Technical Activity Pattern sowie dem Page Object haben Sie 2 Werkzeuge, mit denen sich wartbare GUI-Tests schreiben lassen.

Wichtig ist auch, dass man es mit den GUI-Tests nicht übertreibt. Jede Kombination einer Loginmaske (nur Benutzername leer, nur Passwort leer usw.) zu testen wäre unsinnig. Versetzen Sie sich dazu am besten in die Lage der Benutzer Ihrer Applikation. Diese werden entweder das richtige oder falsche Login eingeben.

Des Weiteren sollten Sie Unit- und Integrationstests für den Rest Ihrer Applikation durchführen. GUI-Tests sind nur das Tüpfelchen auf dem i.

Zu guter Letzt: warum_sind_die_tests_so_geschrieben? Wenn Sie genau aufgepasst haben sehen Sie, dass nur die Methoden die zum Business Rule-User Interface Workflow-Technical Activity Pattern gehören so geschrieben wurden.

Bei Tests sehe ich nun sofort, dass der Methodenname die Business Rule und die Implementation davon der User Interface Workflow ist. Die privaten Methoden sind die Technical Activities mit den Page Objects. Es erinnert mich auch daran, dass es sich hier explizit um GUI-Tests handelt und diese Patterns angewendet werden.

Natürlich können Sie dieNormaleJavaForm verwenden.

Weiterführende Ressourcen

Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

Xpert.ivy mini Kontakt Mobile App

Ich hatte heute etwas Zeit um eine kleine Kontakt Mobile App mit Xpert.ivy und PrimeFaces Mobile zu schreiben.

Abb. 1: Kontakt Mobile App
Sie zeigt, wie man eine Liste von Kontakten anzeigen und filtern kann und wie man eine Detail Seite des ausgewählten Kontaktes anzeigt.

Der Source Code kann unter http://xpert-ivy-hacker-source-code.googlecode.com/svn/trunk/ContactsMobileApp ausgecheckt werden.

Viel Spass!
Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.

Rothorn Sprint 10 Review Meeting

Heute wurden die Ergebnisse von Rothorn Sprint 10 präsentiert. Ein Sprint voller Highlights!
  • Embedding von Html User Dialogen
  • Managed Beans
  • Quickfix für fehlende Events, Methoden und Datenklassen-Attribute
Das Embedding erlaubt es Html User Dialoge in andere Html User Dialoge einzubetten und somit wiederverwendbare Komponenten zu schreiben. Ein Kritikpunkt der dazu aufkam war, dass man beim erstellen eines Html User Dialoges nun ein View Layout auswählen muss.

Abb. 1: View Layout
Dies bestimmt, ob ein Html User Dialog in einen anderen Html User Dialog eingebettet werden kann (Component) oder nicht (Page). Dies ist mit ULC nicht nötig.

Meiner Meinung nach ist dies nicht weiters tragisch, da die meisten Html User Dialoge Component sein sollten und über eine Page zusammen gesetzt werden bzw. in anderen Components eingebettet werden.

Ein Beispiel dazu wäre, ein Layout als Page zu verwenden und in dieses Layout alle Components einzubetten.

Ein weiteres Feature von ULC das vermisst wurde sind die Events die eine Komponente senden und empfangen kann. Dies gibt es zur Zeit für Html User Dialoge nicht. Der JSF Standard bietet jedoch mit actionSource eine Möglichkeit, Events an die äusseren Komponenten zu senden.

Des weiteren werden nun Managed Beans unterstützt. Diese können per @ManagedBean Annotation definiert und in der View verwendet werden.

Klein aber fein ist das neue Quickfix Feature. Damit kann man per CTRL+1 Events, Methoden und Datenklassen-Attribute, die in der View referenziert werden aber nicht existieren, automatisch erstellen lassen und braucht nicht die Logic, das Interface bzw. die Datenklasse zu öffnen.

Das Sprint Inkrement steht zum Download bereit.
Über den Author: Heinrich Spreiter ist der Gründer von xpertivyhacker.ch. Kontaktieren Sie ihn auf Xing und Twitter

Melden Sie sich für den Xpert.ivy hacker Newsletter an und Sie erhalten immer die neusten Tutorials und Tricks zu Xpert.ivy sobald sie publiziert werden.

Ihre Email Adresse wird nur für diesen Newsletter verwendet und nicht an dritte weitergegeben.