Wicket mit Fitnesse testen

Bei unserem letzten Projekt haben mein Kollege Tjeerd Kaastra und ich Wicket verwendet. Da unsere GUI so komplex war und wir Hunderte von Unit-Tests schreiben mussten (eine Menge Eckfälle), haben wir uns mit unseren Testern zusammengesetzt, um herauszufinden, wie wir vorgehen sollten. Da unsere Tester Fitnesse verwenden, um sowohl funktionale Akzeptanz- als auch Regressionstests durchzuführen, testen sie auch einen großen Teil des Codes. Also dachten wir uns, warum nicht beides miteinander verbinden, und das haben wir getan. Dieser Blog beschreibt, wie man Wicket-Anwendungen mit Fitnesse testet. Es geht darum, die Grenzen der Wicket-Testkomponenten zu erweitern, um dies zu tun. Wir werden versuchen, dies anhand eines kleinen Beispielprojekts zu erklären, das wir zur Veranschaulichung erstellt haben. Dieses Beispielprojekt wurde durch das neue Beispiel für einen Benutzerassistenten von Eelco Hillenius inspiriert. Wir haben dieses Beispiel so angepasst, dass es Spring verwendet, da die meisten Anwendungen ein Backend-System verwenden.

Für diejenigen, die nicht wissen, was Fitnesse ist: FitNesse ist ein Webserver, ein Wiki und ein Softwaretest-Tool. FitNesse ermöglicht es Benutzern, speziell formatierte Eingaben zu machen (das Format ist auch für Nicht-Programmierer zugänglich). Diese Eingaben werden interpretiert und es werden automatisch Tests erstellt. Fitnesse bietet also großartige Möglichkeiten für automatisierte Tests über Ihre Unit-Tests hinaus. Wicket verfügt über einige Dienstprogramme, mit denen Sie die GUI Ihrer Anwendung außerhalb eines Containers testen können. Diese Komponenten sind org.apache.wicket.util.tester.WicketTester und speziell für Formular-Komponenten gibt es org.apache.wicket.util.tester.FormTester. Wäre es nicht toll, wenn wir diese Unit-Test-Komponenten für funktionale Tests in Fitnesse verwenden könnten? Formulare können mit dem FormTester getestet werden. Aber leider ist der FormTester nur für ein Formular gedacht. Wie bei einem Unit-Test üblich, schreiben Sie für jedes Szenario einen eigenen Testfall. Aus funktionaler Sicht möchten Sie vielleicht das Absenden eines Formulars testen, dann zur Seite zurückkehren, einige Validierungsprobleme korrigieren und das Formular erneut absenden. In der Praxis verwenden wir eine abstrakte Fixture-Klasse, die alle generischen Methoden bereitstellt, und eine erweiterte Fixture, die uns alle Implementierungsdetails liefert (wie den korrekten Anwendungskontext, die Modellklasse, die Startseite usw.). Die abstrakte Fixture hat zum Beispiel Methoden, um zu prüfen, ob Komponenten vorhanden sind, Set- und Select-Methoden und vieles mehr. Sehen Sie sich das Beispielprojekt an. Außerdem werden Sie im gesamten Code mehrere boolesche Rückgabewerte sehen, die scheinbar nicht verwendet werden. Dies ist eine Best-Practice der Fitness. Immer, wenn ein boolescher Wert zurückgegeben wird, färbt der Fitnesse-Test die Ergebniszelle grün oder rot, damit Sie überprüfen können, ob die Methode ausgeführt wurde. Testen des Assistenten Für diejenigen, die die Assistenten-Komponente nicht kennen: Eine Assistenten-Komponente ist eine Dialogkomponente, die ihre Benutzer durch eine Reihe von vordefinierten Schritten führt. Sie verfügt über gängige Funktionen wie die Schaltflächen "Weiter", "Zurück", "Beenden" und "Abbrechen" und verwendet Übergangsregeln, damit die Kunden durch die einzelnen Schritte navigieren können. Hier sehen Sie eine typische Fitness-Tabelle, die Sie zum Testen Ihres Ablaufs verwenden können:

Sieht doch ganz einfach aus, oder? Nun, es sind einige Schritte erforderlich, um dieses einfache Testszenario zu erreichen, und natürlich gibt es auch ein paar Probleme. Problem 1: Verwendung von Feldwerten anstelle von Indexnummern Normalerweise müssen Sie mit WicketTester für alle Felder, die Sie testen wollen, Indizes definieren. Beim Schreiben von Unit-Tests ist das kein Problem, aber da wir für funktionale Tests sorgen wollen, müssen wir dafür Reflection verwenden. Wir werden nicht in die ReflectionUtils gehen, aber die setFieldValueThroughSetMethode setzt einen Wert für ein bestimmtes Feld über die entsprechende Set-Methode. Da wir dazu neigen, ListView-Komponenten für die Wiederholung von Formularelementen zu verwenden, haben wir auch eine spezielle Methode hinzugefügt, um einer Komponente an einer bestimmten Position in der Liste, die die ListView verwendet, einen Wert hinzufügen zu können. Problem 2: Mehrfaches Absenden und Feedback Das eigentliche Absenden hat mehrere Probleme zu lösen: FormTester erlaubt nur einen RequestCycle, d.h. Sie können ein Formular nur einmal absenden und müssen danach Ihren Testfall erneut einrichten. Der Formtester aktualisiert auch nicht das Modell, da er nur einen Schritt testet.Da der Submit nur den lokalen Schritt testet, müssen wir .onSubmit() auf der Next-Schaltfläche aufrufen, um mit dem nächsten Schritt fortzufahren.Feedback-Meldungen gehen verloren, wenn Sie ein Formular sowohl mit FormTester als auch mit WicketTester abschicken. Wenn Sie einen Feldwert festlegen, speichern Sie diesen Wert in einer Map, die als Zwischenspeicher verwendet wird. Rufen Sie bei der Übermittlung zunächst die WebSession ab und entfernen Sie alle Feedback-Meldungen. Setzen Sie dann alle Feldwerte, die Sie im Formular zwischengespeichert haben, erneut. Wir übermitteln dann den FormTester, um das Verhalten des Formulars zu validieren, und wenn alles gut geht (d.h. keine Fehlermeldungen durch die Validierung der Formulareingaben auftreten), gehen wir zum nächsten Schritt über. Problem 3: ListViews werden nicht automatisch gerendert Da Sie Werte auf nicht gerenderten Komponenten nicht aktualisieren können, müssen wir unsere ListView-Komponenten manuell rendern. Wenn wir zu einem anderen Schritt übergehen, sollten wir daher die Komponenten rendern, siehe RenderComponents() im Abstract Fixture. Problem 4: Werte auf Objektattribute abbilden. Da gerenderte Werte Strings sind, z.B. haben wir in unserer Beispielanwendung ein Benutzerobjekt, das eine Liste von Rollen hat, zeigen wir nur den Rollennamen des Rollenobjekts an. Wir müssen in der Lage sein, einen Eingabestring auf ein Objektattribut abzubilden. Wenn wir also in Fitnesse sagen

Einer der Vorzüge eines komponentenbasierten Frameworks ist, dass Ihre GUI-Komponenten durch echte Java-Objekte unterstützt werden. Das macht es jedoch schwieriger zu testen, ob ein Feld wie erwartet gefüllt ist. Beim Einrichten eines Fixtures müssen wir eine Karte der Objekttypen und der entsprechenden GI-Felder erstellen. Fügen Sie dies zu Ihrer Initialisierungsmethode hinzu: addTypeAndFieldName("Role", "roleName"); addCustomComponent("org.apache.wicket.markup.html.basic.Label"); addCustomComponent("org.apache.wicket.markup.html.list.ListView"); Lassen Sie uns also ein paar Tests veranschaulichen. Test 1:

• Prüfen Sie, ob die erwarteten Komponenten auf der NewUserWizardPage vorhanden sind. In Ihrem Browser sieht die Seite wie folgt aus:

  Der Fitnesstest sieht folgendermaßen aus:

  

  Wie Sie sehen können, ist es einfach und gut lesbar. Wie Sie sehen können, entspricht unser Test Punkt 3. Die Tester müssen den voll qualifizierten Namen für RequiredTextField nicht ausfüllen. Um dies zu ermöglichen, führen wir eine interne Karte der vollqualifizierten Namen der Komponenten. Wenn Sie über Komponenten verfügen, die nicht im Paket org.apache.wicket.markup.html.form. enthalten sind, müssen Sie sie hinzufügen, indem Sie eine Zeile wie addCustomComponent("org.apache.wicket.markup.html.basic.Label"); zur Initialisierungsmethode in der Fixture hinzufügen). Test 2:

• Klicken Sie auf die Schaltfläche "Weiter" und überprüfen Sie, ob es Fehler gibt und ob wir uns im richtigen Schritt des Assistenten befinden. In Ihrem Browser sieht die Seite wie folgt aus:

  Der Fitnesstest sieht folgendermaßen aus:

  

  Test 3:

• Geben Sie den Benutzernamen ein und klicken Sie auf die Schaltfläche "Weiter". Prüfen Sie, ob es Fehler gibt und ob wir uns im richtigen Schritt des Assistenten befinden, geben Sie dann die E-Mail-Adresse ein und klicken Sie auf die Schaltfläche "Weiter". Der Fitness-Test sieht so aus:

  Dies sind nur einige Beispiele dafür, wie Sie Ihre Wicket-Anwendung mit Fitnesse testen können. Wie Sie sehen können, ist es sehr einfach zu testen und es ist lesbar! Durch die Kombination der Leistungsfähigkeit von Fitnesse und Wicket ermöglichen wir es auch Nicht-Technikern, automatisierte Tests zu schreiben. Auf diese Weise wird Ihre Benutzeroberfläche in jeder Iteration innerhalb weniger Stunden vollständig getestet. Das bedeutet eine erhebliche Qualitätsverbesserung und beschleunigt das Testen erheblich (stellen Sie sich vor, wie viel Zeit es kosten würde, einen Regressionstest von Hand durchzuführen!) Unser Projekt hat gezeigt, dass diese Kombination sowohl für Entwickler und Tester als auch für unseren Kunden sehr wertvoll ist.Die Quellen des Beispielprojekts finden Sie hier. Lesen Sie die Datei installation.txt im Verzeichnis src/main/documents, um mit der Beispielanwendung zu beginnen.