Nightwatch und ich – (k)eine Lovestory~ 7 min.

Code Beispiel Nightwatch Katjasays

 

Bei der Arbeit wurden schon immer Tests vor und nach Deployments sowie ein permanentes Monitoring durchgeführt. Diese wurden allerdings zumeist manuell durchgeführt. Das bedeutet, dass meine Kollegen sich immer mit mehreren Devices hingesetzt und die Internetseiten durchgetestet haben – sowohl auf Funktion als auch auf Design. Auf Dauer kamen immer mehr Features dazu und es wurde immer aufwendiger, alles manuell durchzutesten, zumal man auch nicht die Zeit hatte, jeden Tag alles anzuschauen und daher Fehler manchmal erst nach einer Weile aufgefallen sind. Um dies zu ändern, sollte ein automatisiertes Testen eingeführt werden.

Als ich die Rolle der QA-Managerin übernommen habe, wollte ich dies schnellstmöglich in die Tat umsetzen. Dies heißt nicht, dass gar nicht mehr manuell getestet werden soll, denn einige Dinge muss man sich einfach an einem realen Device anschauen bzw. gerade auch das Design und die UX. Aber um ein permanentes Monitoring garantieren zu können, hilft es einfach, wenn man die wichtigsten Dinge automatisch nachprüft. Da ich Lust darauf hatte und es mir sehr am Herzen lag, alles schnell umzusetzen, ohne die Entwickler aus ihrer Arbeit herauszureißen, habe ich diese Aufgabe übernommen.

Wir haben uns dazu entschlossen, das Monitoring mit Nightwatch umzusetzen. Auf der Seite steht: „Browser automated testing done easy.“ – klingt ja erstmal ganz gut. Und der Aufbau der Tests sieht auch sehr logisch aus mit Elementen wie client.waitForElementPresent etc.. Also habe ich mir nun Testfälle überlegt und diese erstellt. Einfachere Dinge, wie das Warten auf ein Element, das Bewegen der Maus zu einem bestimmten Element oder auch zu sehen, ob eine erwartete Eigenschaft (z.B. .expect.element.to.be.present) zutrifft, sind mir relativ leicht gefallen.

Aber wenn man dann mal eine etwas schwierigere Abfrage machen wollten, war es nicht so leicht, diese für Nightwatch kompatibel zu schreiben. Was mir dabei aufgefallen ist, ist, dass die Dokumentation relativ schlecht ist. Man findet zwar Infos darüber, was für Elemente es gibt und was man abfragen kann, aber dazu gibt es so gut wie gar keine Beispiele, sodass man ziemlich auf sich alleine gestellt ist. Auch Stack Overflow bietet nicht wirklich viele Anhaltspunkte. Somit bin ich das ein oder andere Mal kurz vor dem Verzweifeln gewesen und musste stundenlang hin und her experimentieren, bis ich den richtigen und funktionierenden Code gefunden habe, der zum Erfolg geführt hat. Hier auch nochmal einen großen Dank an meine Kollegen, die mich dabei unterstützt haben.

Hier mal 2 Fälle. die euch vielleicht dabei weiterhelfen, bestimmte Dinge in Nightwatch zu checken:

Status Code in Nightwatch abfragen

Hiermit könnt ihr abfragen, ob die Quelle eines Bildes in Ordnung ist, indem ihr euch diese einfach anzeigen lasst. Ebenso könnt ihr den Statuscode der Bild URL abfragen und damit sehen, ob es einen Statuscode 200, also einen „success“ auswirft.

// Check if src of image is ok and the status of result is "success"
client.getAttribute('.class', 'src', function (result) {
this.assert.ok(result.value, '(value of image src)');
this.assert.equal(result.state, 'success', 'Status of image is "success"');
});

In Nightwatch prüfen, ob ein Element wirklich sichtbar ist

Es gibt zwar die Abfrage expect.element.to.be.visible, aber diese besagt nur, ob das Element das Attribut visible hat. Man kann dadurch nicht erfahren, ob es nicht vielleicht von einem anderen Element überdeckt wird. Hiermit könnt ihr sehen, ob ein Element wirklich sichtbar ist:

check_element_is_visible: function (client, cssSelector, moveToSelector) {

        client.waitForElementVisible(moveToSelector, config.browser.globals.wait, false, function () {
            client.moveToElement(moveToSelector, 0, 200);

            client.pause(config.browser.globals.pause);
            client.isVisibleOnScreen(cssSelector);
        });
    },

Nightwatch – keine Lovestory für mich

Da ich gemerkt habe, dass das Schreiben von Tests in Nightwatch ein echter Zeitfresser sein kann und man durch Googlen auch nicht hundertprozentig die richtige Lösung findet, die man benötigt, haben wir uns überlegt, auf ein anderes System umzusteigen. Da wir einiges über Cucumber und Gherkin gehört haben und uns die Art der Testfall-Formulierung mit Gherkin gut gefällt, probieren wir gerade aus, unsere Tests dorthin zu übertragen. Ich bin gespannt, ob Cucumber uns besser gefallen wird.

Cucumber im Test

In der Zwischenzeit haben wir tatsächlich automatisierte Tests mit Cucumber ausprobiert. Ich muss sagen, dass mir die Gherkin Syntax sehr gut gefällt, da die Test-Scenarios so viel besser lesbar sind und theoretisch auch „jeder“ diese schreiben könnte. Danach müssten diese dann „nur noch“ von einem Entwickler oder einem technisch versierteren Tester nachprogrammiert werden.

Wer mit der Gherkin Syntax nicht so vertraut ist, so sieht diese aus:

Gherkin Syntax Beispiel

Man beschreibt ein Feature und führt darunter die zu testenden Szenarien auf. Diese bestehen aus Bedingungen und erwünschten Folgen, die man testen möchte. So könnte man in einem Szenario z.B. testen, ob nach Aufruf einer bestimmten URL und einer Eingabe in ein Formular eine Bestätigung/ein Fehler aufploppt oder Ähnliches.

Ich habe Cucumber in Ruby ausprobiert (obwohl man das eigentlich mit jeder Programmiersprache machen kann, wie z.B. JavaScript, Java, Ruby, PHP, etc.), da mir die Programmiersprache ganz gut gefallen hat und man zudem noch Capybara nutzen kann. Nein, nicht das niedliche Tierchen, sondern das Akzeptanz-Test Framework. Dieses bringt eine sehr nette DSL mit, mit der man z.B. sehr einfach mit Formularen interagieren oder nach Elementen auf der Seite suchen kann. Von der Grundidee war alles super, die Tests gingen schnell und relativ leicht von der Hand und auch die Syntax war gut zu schreiben. Allerdings wollte ich die Tests nicht nur mit PhantomJS headless testen, sondern in diversen Browsern auf diversen Devices. Dazu wollte ich gerne Browserstack benutzen, mit dem man die Cucumber/Capybara Tests laut Anleitung relativ einfach verbinden kann. Bei uns hat es dann daran gehapert, dass wir ziemlich viele Devices und Browser testen wollten und die parallele Ausführung von Tests zur Verringerung des Zeitfaktors nicht richtig klappen wollte. Wir wollten die Tests über Jenkins starten lassen und dann in Browserstack ausführen, doch irgendetwas hat dabei nicht gepasst.

Bevor ich mich nun daran gemacht habe, alles zu reparieren und dort noch mehr Zeit hinein zu stecken, habe ich mich dafür entschieden, erstmal nach einer Alternative zu schauen. Und wer hätte es gedacht, ich bin wieder zurück zu Nightwatch geswitcht.

Nightwatch – Vielleicht doch eine Lovestory?

Nach nunmehr einem Jahr ohne dass ich wieder in Nightwatch geschaut habe, hat sich einiges verändert. Die Community ist gewachsen und man findet nun viel mehr Informationen, wenn man auf irgendwelche Problematiken stößt oder Fragen zu Funktionen hat. Vielleicht gab es das vorher wirklich nicht oder ich habe es einfach nicht gewusst, wenn einem Commands oder Assertions fehlen, kann man diese einfach selber schreiben und damit Nightwatch erweitern. Dies ist sehr praktisch und ist bei uns auch zum Einsatz gekommen. Man schreibt die Custom Command / Custom Assertion und kann sie danach in seinen Tests ganz einfach benutzen. Die Tests selber sehen gut aus und man kann sie relativ kurz halten. Besonders praktisch finde ich, dass man die Schritte super aneinander reihen kann:

Nightwatch Test Example

Was uns bei Nightwatch allerdings fehlt, ist eine schöne Art der Beschreibung von Tests, wenn z.B. der PO eines Projekts gerne Akzeptanzkriterien festlegen möchte, aber selber keine Tests schreiben kann/möchte. Ja, man könnte Kommentare nutzen oder einfach eine Textdatei, aber das ist nicht sehr elegant und der Programmierer müsste dann die gesamte Test-Datei selber machen. Gibt es da nicht eine schönere Lösung?

Nightwatch und Cucumber – Happy End einer Lovestory

Was uns bei Cucumber so gut gefallen hat, ist die schöne Syntax, die mit Gherkin geschrieben wird. Bei Nightwatch gefällt uns allerdings die schöne Darstellung der Testschritte und das Aneinanderreihen von Schritten im Text. Warum kann man das nicht einfach verbinden? Kann man. Auch wenn der Nutzername mucsi96 nicht allzu vertrauenserweckend ist, hat dieser ein echt cooles Modul geschrieben, mit dem man einen BDD (Behaviour Driven Development) Ansatz für Cross-Browser-Tests starten kann: nightwatch-cucumber. Hiermit lassen sich die Beschreibung der User-Stories mit der Gherkin-Syntax aus Cucumber mit den Assertions und Commands aus Nightwatch verbinden. Das heißt, man hat hiermit das Beste aus beiden Frameworks in einem. Man kann die Tests entweder in einem realen Browser, einem headless Browser oder einem cloudbasierten Service wie Browserstack laufen lassen. Also genau das, was wir brauchen. Aktuell sind wir dabei, unsere Tests umzuschreiben und die Gherkin Syntax zu ergänzen. Das hat nun den Vorteil, dass der PO (oder wer auch immer) die Testfälle mithilfe der Gherkin-Syntax sehr einfach aufschreiben kann und der Programmierer wirklich „nur noch“ dahinter programmieren muss. Was will man mehr?

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (5 Bewertungen, Durchschnitt: 4,80 von 5)
Loading...
Kommentare
  1. […] System als eins betrachten und kann zum Testen Tools wie Appium, Selenium, Cucumber, Gherkin oder Nightwatch nutzen. Man muss sich zu Beginn gut überlegen, welche Features in welchen Service gehören und […]

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.