DalekJS erlaubt es, Tests in JavaScript in einer jQuery-ähnlichen Umgebung zu schreiben

DIY-Testing-Tool
Kommentare

Machen wir uns nichts vor, in den vergangenen Jahren hat sich die Komplexität der von uns gestalteten Frontends vervielfacht. Dabei ist nicht nur die Codekomplexität ein Thema, auch die zu bedienenden Zielplattformen haben sich durch den Zuwachs in der Familie der mobilen Endgeräte und die immer kleiner werdenden Intervalle zwischen Browserversionen exponentiell vermehrt. Was dadurch vor allem in kleineren Projekten auf der Strecke bleibt, ist die Qualitätskontrolle.

Verdeutlichen wir die Situation doch erst mal an einer Problemstellung, die jedem von uns sicherlich schon einmal so oder so ähnlich begegnet ist: Nehmen wir mal an, wir sind einer der Frontend-Entwickler in einem Team, das ein Onlineshopsystem betreut. Eines der meist genutzten Features ist die prominente Artikelsuchmaske, die auf jeder Seite zu finden ist. Ein kritisches Feature ist es zudem, denn funktioniert die Suchmaske nicht, ist der potenzielle Kunde nicht in der Lage, eine Auswahlliste geeigneter Produkte angezeigt zu bekommen und findet dadurch auch nicht den Weg auf die Detailseite eines Produkts. So weit, so gut. Jetzt aber kommt der Chef mit einem neuen Feature, das augenscheinlich gar nichts mit der Suchmaske zu tun hat, jedoch zwei, drei Änderungen am bestehenden Code nötig macht. Wir entwickeln das Feature und nach einem kurzen Check scheint alles perfekt zu funktionieren, die Unit Tests laufen durch. Alles geht seinen geregelten Gang, wir committen den Code ins Repository, der Continous-Deployment-Prozess greift automatisch, wir holen uns einen Kaffee, kommen an den Schreibtisch zurück und da steht er, der Chef. Mit grimmigem Gesichtsausdruck wird uns berichtet, dass keiner der Kunden über Chrome die Suchmaske nutzen kann. Zeit für einen Rollback, allerdings hat in der Zwischenzeit der Kollege auch einen anderen Fix eingespielt, also versuchen wir zu mergen, nichts läuft mehr … Okay, Zeit, dieses Horrorszenario zu verlassen – wie eingangs erwähnt: Viele von uns hatten sicherlich schon mal solch ein Erlebnis in ihrer Karriere.

Von anderen Bereichen lernen

Wie auch unser hypothetisches Shoppingportalteam haben wir uns dann Gedanken gemacht, wie wir solche Probleme in Zukunft vermeiden können. Eine bewährtes Mittel, bekannt unter anderem aus dem Pilotenhandwerk, sind Checklisten. Bevor wir, beziehungsweise unser Code „abhebt“, versichern wir uns, dass alles funktioniert: 1. Schritt 1: Öffne Firefox. 2. Schritt 2: Tippe %Produktname% ins Suchfeld. 3. Schritt 3: Klicke den „Suchen“-Button. 4. Schritt 4: Prüfe, ob das Testprodukt in der Liste auftaucht. 5. Schritt 5 bis 257: Wiederhole dies in allen möglichen unterstützten Betriebssystemen und Browservarianten. Klar, für Piloten mag dies ein probates Mittel sein – für die Webentwicklung ist es gänzlich ungeeignet, da extrem zeitaufwändig und, durch die menschliche Komponente, auch fehleranfällig. Im Umkehrschluss brauchen wir also etwas, dass uns die Arbeit abnimmt. Etwas, auf das wir uns verlassen können, etwas, was automatisch die kritischen Stellen in unserer Software testet – am besten so, dass wir im Erfolgsfall gar nicht merken, dass es da ist. Eine Bestandsaufnahme ist angesagt: Welche Features sind uns als Frontend-Entwickler für unser Projekt wichtig?

Roadmap Begeben wir uns in die nähere Zukunft, werden wir sehen, dass die Evolution von DalekJS grade erst begonnen hat. Die wichtigste Errungenschaft, neben dem Beseitigen der zahlreichen Bugs, werden der Rewrite der Core Engine und die damit einhergehende Verbesserung der APIs darstellen. Auch das geplante Plug-in-API, wieder stark inspiriert von der jQuery-Welt, wird hoffentlich die Nützlichkeit des Frameworks im Ganzen stark verbessern. Mit mittlerweile unzähligen verstreuten Gists und Code-Snippets, wie zum Beispiel AngularJS-spezifischen Testszenarien, wird der Ruf nach einem generischen Plug-in-API und einer zentralen Anlaufstelle immer lauter. Ein anderes wichtiges Feature, um die Zukunftssicherheit von Applikationstests sicherzustellen, wird die Integration eines Feature-Detektion-Helfers à la Modernizr. Dies wird besonders wichtig in Szenarien, in denen schon die zu testende Webseite Feature Detection nutzt, um Features progressivly enhanced bereitzustellen. Browser-Sniffing gehört der Vergangenheit an, und auch Testing-Frameworks dürfen sich dem nicht länger verschließen.

Eine Bestandsaufnahme

Das Tool sollte uns erlauben, die Tests in JavaScript zu schreiben, da es die Sprache ist, mit der jeder Frontend-Entwickler firm sein, und die auch dem einen oder anderen Entwickler, der im Web unterwegs ist, geläufig sein dürfte. Um nicht direkt abschreckend zu wirken, sollte sich das Tool an den APIs und der Simplizität von jQuery orientieren, also eine einfache Abstraktion analog zur täglichen Arbeitsumgebung abbilden. Wo wir uns grade in der jQuery-Thematik befinden: Auch die Installation sollte so einfach sein wie das Einfügen eines jQuery-Plug-ins in eine Webseite. Niemand mag es, sich endlose Blog-Posts durchzulesen und eine stundenlange Konfigurationsarie zu starten, bevor das Tool läuft. Ein ganz anderer, aber umso wichtigerer Punkt, ist: Das Tool sollte es uns erlauben, die Tests in „richtigen“ Browsern auszuführen. So toll und flexibel Headless-Browser wie PhantomJS, SlimerJS oder TrifleJS auch sind, sie können keinen Browser zu 100 Prozent abbilden; und auch keiner unserer Kunden wird mit solch einem Browser unseren Shop besuchen. Auch andere Software, die wir in unserem Gebrauch haben, wie GruntJS, sollten sich nahtlos mit dem Tool unserer Wahl integrieren lassen. Wir als Webentwickler leben nach den Standards. Anders geht es gar nicht, um unsere Seiten und Apps Cross-Browser zum Leben zu erwecken, und auch unsere Testing-Tools sollten sich daran halten – passt uns die Implementierung oder Art und Weise eines Frameworks nicht, so können wir einfach auf ein anderes Umschwenken, ohne die Infrastruktur komplett über den Haufen zu werfen.

DalekJS

Als unser Team Ende 2012 solch ein Tool bitter nötig hatte, gab es kein einzig verfügbares, das alle diese Kriterien erfüllte. Als Entwickler und Teil der Open-Source-Community lag also nur ein Schluss nahe: Wenn es kein Tool gibt, dann erschaffen wir eins. Das war die Geburtsstunde von DalekJS. DalekJS basiert auf der Webdriver-Spezifikation, steuert sowohl Headless-Browser als auch die „echten“, hat ein GruntJS-Plug-in und ein einfaches, an jQuery angelehntes API, um Tests in JavaScript zu schreiben.

Installation

Wie weiter oben im Text beschrieben, sollte die Installation so straight forward wie möglich sein. Um das zu ermöglichen, wollten wir Dalek mit so wenig Abhängigkeiten wie möglich versehen; genaugenommen nur mit einer einzigen: Node.js. Von Haus aus hat Node.js seinen Package Manager npm mit im Gepäck – im Prinzip nichts anderes als Composer; ein einfaches Stück Software, um die Abhängigkeiten seiner Applikation zu verwalten. Eben dieses Tool nutzen wir, um als aller Erstes die Dalek-CLI-Tools zu installieren:

npm install -g dalek-cli

Danach sollten wir ein neues Kommando namens dalek in unserer Kommandozeile zur Verfügung haben. Um nachzuschauen, ob alles funktioniert hat, können wir dalek -v ausführen, das uns mit einer freundlichen Botschaft darauf aufmerksam machen sollte, dass wir noch das Basisframework installieren müssen. Um das zu tun, gehen wir in das Root-Verzeichnis der Anwendung, die wir testen möchten, und führen folgenden Code aus: npm install –save-dev dalekjs. Dieser installiert das Dalek-Core-Framework in das /node_modules/-Verzeichnis unserer Anwendung. Für alle, die sich fragen, warum zwei Schritte bei der Installation nötig sind: Der Grund für die Trennung der CLI-Tools und des Coreframeworks ist, die Updatefähigkeit von Dalek zu erhalten, ohne ältere Tests in anderen Anwendungen in ihrer Ausführbarkeit zu behindern. Haben wir etwa vor sechs Monaten noch Tests basierend auf der Dalek-Version 0.1.0 geschrieben und Version 0.2.0 hat eine Änderung des API eingeführt, könnten wir nicht einfach updaten und die neuere Version nutzen. Da nun aber der Kern von Dalek projektspezifisch installiert wird, können wir für neuere Anwendungen eine neuere Dalek-Version nutzen und trotzdem auch unsere älteren Tests ohne Probleme ausführen.

[ header = Seite 2: Ein simples Beispiel ]

Ein simples Beispiel

Nun, da Dalek installiert ist, können wir uns ganz unseren Tests widmen. Um diese sinnig ablegen zu können, erstellen wir zunächst einen Ordner, in dem wir sie ablegen. Für unser Beispiel nennen wir den Ordner /test/ – einen anderen Namen zu wählen, ist jedem freigestellt. Um die Lernkurve weiter schön niedrig zu halten, erstellen wir erst mal einen ganz simplen Testfall für unser Onlineshoppingportal – nennen wir es thames.com – und schauen, ob der Inhalt des Titeltags auf der Startseite unseren Vorstellungen entspricht. Dazu öffnen wir eine neue Datei und fügen den Code aus Listing 1 ein.

module.exports = {
  'Title is as expected': function (test) {
    test.open('http://www.thames.com/')
        .assert.title('Thames.com: Online Shopping for Electronics', 'Title matches the expectations')
        .done();
  }
}

Für die Node.js-Agnostiker unter uns: Das module-Objekt ist eine globale Variable, die in jeder mit Node.js ausgeführten Datei vorhanden ist. Die exports-Eigenschaft sorgt dann dafür, dass der Inhalt „exportiert“ werden kann. Damit machen wir den Inhalt public und für Dalek verfügbar. Im regulären Node.js-Umfeld kann module.exports alles zurückgeben – Funktionen, String, ganz egal. Damit in unserem speziellen Fall diese Testsuite von Dalek ausgeführt wird, muss aber immer ein Objektliteral zurückgegeben werden, das die einzelnen Test-Units als Funktionen enthält. Bevor wir jetzt dazu übergehen, das Beispiel durch den Test-Runner zu jagen, schauen wir uns doch erst noch die Anatomie des Tests an. Wie der aufmerksame Leser sicherlich schon herausgefunden hat, ist „Title is as expected“ der Name der Test-Unit. Das Argument, das der Funktion später durch Dalek übergeben wird, wird dazu genutzt, die Aktionen, die der Test-Runner ausführen soll, zu definieren. Innerhalb der Dalek-Welt sprechen wir übrigens von actions und assertions, um die zwei grundlegenden Interaktionen zu unterscheiden, die in unserem test-Objekt vorhanden sind.

Actions definieren das Interface, um den Browser fernzusteuern, das heißt, um ihn auf einen bestimmten URL zu lenken, Text in ein Formfeld einzugeben, und um auf Links innerhalb eines Dokuments zu klicken. Assertions wiederrum sind der Gegenpart der Actions; sie sind dafür zuständig, die Daten, die vom Browser zurückgeschickt werden, auszuwerten. Assertions sind daran zu erkennen, dass sie immer .assert als Präfix erhalten. In unserem einfachen Beispiel benutzen wir die Aktion open, um zu unserer Teilseite thames.com zu navigieren. Dann wiederrum benutzen wir die title-Assertion, um den Webseitentitel zu verifizieren. Wichtig dabei: Der Inhalt des Tags wird nicht via Web Scraping geladen, sodass Dalek auch nachträglich auf Veränderungen des Titels, etwa via JavaScript, reagieren kann. Die title-Assertion nimmt zwei Argumente entgegen: Das erste ist der Title, gegen den geprüft werden soll, also die Angabe, die wir als richtig erachten. Das zweite Argument ist optional, ein Freitextfeld, das es nachher, etwa im Fehlerfall, einfacher macht, die fehlgeschlagenen Assertions zu identifizieren. So, jetzt wird es aber langsam mal Zeit, Dalek etwas zu tun zu geben und den Test auszuführen. Glücklicherweise kommt DalekJS in seiner Basisinstallation direkt mit PhantomJS huckepack. Speichern wir also die geöffnete Datei als simple.js in unserem Ordner /test/ ab, öffnen unsere Kommandozeile, navigieren zu dem Root-Verzeichnis unserer Applikation und tippen dalek test/simple.js ein. Damit starten wir den Test-Runner und nach kurzer Zeit sollte ein Output ähnlich dem in Abbildung 1 zu sehen sein.

Abb. 1: Dalek-Konsolenausgabe

Userinteraktion

Nur den Titel einer Seite zu checken, ist auf Dauer langweilig, und manch einer könnte auch argumentieren, dass Texte zu prüfen, nicht sonderlich klug ist. Also steigen wir etwas tiefer in die Möglichkeiten von Dalek ein. Wie eingangs bereits erwähnt: Unser kleiner Onlineshop hat ein Suchfeld für Artikel, ähnlich dem von Google. Das dazugehörige HTML beinhaltet ein Textinputfeld und einen „Submit“-Button:

Um jetzt nach einen Artikel, wie zum Beispiel der „Blues-Brothers“-VHS-Kassette zu suchen, können wir unserer bereits existierenden Testsuite einfach eine neue Test-Unit in Form einer neuen Funktion hinzufügen (Listing 2).

module.exports = {
  // ... 
  'Search works': function (test) {
    test
        .type('#twotabsearchtextbox', 'Blues Brothers VHS')
        .click('.nav-submit-input')
        .done();
  }
  // ... 
}

Dieser Schnipsel Code führt zwei Aktionen im Browser aus: Zuerst wird er unsere Suchanfrage „Blues Brothers VHS“ in das Textinputfeld mit der ID #twotabsearchtextbox eingeben. Die zweite Aktion wird danach den „Submit“-Button mit der CSS-Klasse .nav-submit-input suchen und einen Klick darauf ausführen. Die type-Aktion ist übrigens so intelligent, dass sie nicht einfach den String in das Feld postet, nein, sie gibt jeden Buchstaben nacheinander ins Suchfeld ein. Das ist wichtig, damit z. B. jeder JavaScript Event Handler, der in der Applikation an das Element gebunden ist, genau so ausgelöst wird, als würde ein „richtiger Benutzer“ das Suchfeld bedienen. Wenn wir nun davon ausgehen, dass wir nach dem Abschicken des Formulars auf eine Ergebnisseite weitergeleitet werden, können wir unsere Test-Unit ganz einfach um eine Assertion erweitern, die prüft, ob das erste Element in der Ergebnisliste dem entspricht, was wir erwarten:

// ...
.click('.nav-submit-input')
.waitForElement('#result_0')
.assert.text('#result_0 .newaps a span').to.contain('The Blues Brothers [VHS]', 'Article description is fine')
.screenshot('items.png')
.done();
// ...

Die waitForElement-Methode wird benötigt, da wir einen Indikator benötigen, der uns mitteilt, dass die Ergebnisseite geladen wurde. Solange das Element im DOM nicht auftaucht, pausiert der Test. Da die Überschrift des Artikels sich relativ verschachtelt im Markup befindet, müssen wir hier auf einen spezifischeren CSS-Selektor, #result_0 .newaps a span, zurückgreifen. Die Technik, um den Inhalt zu prüfen, ist leicht anders als bei unserem ersten Test, in dem wir den Titel prüften. Im Gegensatz zu dem ersten Test prüfen wir hier nämlich mithilfe eines so genannten assertion helpers, ob der Inhalt nicht gleich ist, sondern nur dem String enthält. Da wir auch unserem, eher visuell geprägten Chef noch eine Freude machen wollen, packen wir noch eine screenshot-Methode mit in den Test, um den aktuellen Status der Seite fest zu halten.

Warum nicht…Selenium Vielen stellt sich sicher die Frage: Warum nicht einfach auf Selenium setzen? Das ist kampferprobt und kann mit Bibliotheken wie wd.js auch ohne Probleme aus einem Node.js-Kontext gesteuert werden. Warum also einen weiteren Konkurrenten schaffen? Zu allererst: DalekJS ist kein Selenium-Konkurrent, es erfüllt einen anderen Nutzen. Die Möglichkeit der einfachen und schnellen Installation, keine Konfigurationsarien durchführen zu müssen – das sind die Features, die Dalek auszeichnen. Dadurch erschließt es eine ganz andere Zielgruppe, nämlich Frontend-Entwickler ohne tiefergehende Kenntnisse im Q&A-Bereich. Damit wird es jedem Entwickler ermöglicht, seine Seiten ohne großen Aufwand zu testen. Das ist das Ziel, auf das wir alle zusteuern sollten.

Multibrowser

Eines der größten Ziele bei der Entwicklung von Dalek war, den Fokus auf die „echten“ Browser zu legen. Bisher haben wir unsere Tests nur in PhantomJS ausgeführt; die Ergebnisse sind zwar sehr nah an denen des Desktop Safari, aber eben auch nicht mehr. Zum heutigen Zeitpunkt kann Dalek mit Google Chrome, Mozilla Firefox, Internet Explorer und dem Safari im iOS-Simulator zusammenarbeiten. Einiger der Browserimplementierungen sind von den Funktionen her kompletter als andere, aber wir hoffen, die existierenden Lücken schnell zu schließen. Um die Tests nun in Chrome laufen zu lassen, müssen wir das dalek-browser-chrome-Add-on installieren. Das ist relativ einfach zu bewerkstelligen. Auf der Kommandozeile, wieder im Root-Verzeichnis unseres Projekts, geben wir Folgendes ein: npm install dalek-browser-chrome –save-dev. Um die Tests nun auch in Chrome auszuführen, starten wir sie mit dem Parameter -b chrome, also dalek test/simple.js -b chrome. Der Browser startet automatisch und wir können uns zurücklehnen und den Tests relaxed beim Durchlaufen zuschauen. Wollen wir nicht nur in Chrome, sondern auch im Internet Explorer testen, ist das Vorgehen prinzipiell gleich. Wir führen npm install dalek-browser-ie –save-dev aus und können dann mit dalek test/simple.js -b chrome,ie die Tests zuerst in Chrome und danach automatisch im IE ausführen. Wollen wir nicht immer die Argumente über die Kommandozeile übergeben, können wir auch eine Datei namens Dalekfile.json in unserem Root-Verzeichnis anlegen und mit folgendem Inhalt versehen:

{
  "browser": ["chrome", "ie"]
}

Es besteht auch die Möglichkeit, Browser in einer virtuellen Maschine oder auf einem anderen Rechner auszuführen. Wie das funktioniert, lässt sich in folgendem Screencast Schritt für Schritt nachvollziehen.

[ header = Seite 3: CI-Integration und Reporting ]

CI-Integration und Reporting

Unsere Tests auf diese Art und Weise auszuführen, ist schon sehr hilfreich. Wenn man aber mal ein Dutzend oder mehr erstellt hat, wird man schnell dem Lesen der Kommandozeilenausgabe überdrüssig. Um auch diesen letzten, manuellen Schritt aus unserem Workflow zu verbannen, können wir Daleks Reporter-Plug-ins nutzen. Das ist besonders nützlich, wenn wir die Tests innerhalb einer CI/CD-Umgebung ausführen, wo Dutzende von Entwicklern gleichzeitig an einer Applikation arbeiten. DalekJS unterstützt momentan, neben der Ausgabe auf der Kommandozeile, die folgenden Reporting-Ausgaben: JSON, JUnit-kompatible XML und HTML. Aber da wir keine Maschinen sind, ist es für unseren Demozweck günstiger, den HTML-Reporter zu nutzen (Abb. 2). Um den Reporter hinzuzufügen, nutzen wir wieder npm: npm install dalek-reporter-html –save-dev. Nun müssen wir nur noch das Reporterargument -r (kurz für —reporter) hinzufügen – dalek test/simple.js -r console,html – und wenn die Tests erneut ausgeführt wurden, wurde ein neuer Ordner namens /report/dalek/ erstellt. Er enthält eine index.html-Datei, die wiederrum eine Liste aller erfolgreichen und fehlgeschlagenen Tests enthält.

Abb. 2: Ausgabe HTML-Reporter

Warum nicht…Karma Im Bereich der JavaScript-basierten Testframeworks ist bisher Karma (ehemals Testacular) der Platzhirsch. Im Umfeld von AngularJS entstanden, hat es grade auch durch dessen Popularität eine starke Verbreitung erfahren. Das größte Problem von Karma ist die zugrunde liegende Technologie selbst: Es nutzt kein Protokoll, um von außen auf den Browser Einfluss zu nehmen, sondern injiziert der zu testenden App oder Seite JavaScript, das im Browser ausgeführt wird und dort die Aktionen von innen triggert. Das ist prinzipiell erst mal eine sehr clevere Technik, allerdings werden auch Events wie click mit JavaScript getriggert. Wenn man sich aber vor Augen führt, welche Eventkaskade im Browser ausgeführt wird, und dass dies auch noch von Browser zu Browser unterschiedlich ist (Abb. 4), muss man feststellen, dass es sehr schwierig bis nahezu unmöglich ist, das zu simulieren.

Remote Testing Service

Will man die Tests nicht immer auf seinem Rechner ausführen und hat keinen Zugriff auf eine belastbare Infrastruktur, ermöglicht es Dalek, sehr einfach auf den Cloud Testing Sevice von Sauce Labs (Abb. 3) zuzugreifen. Sauce bietet eine schier endlose Zahl an Kombinationen verschiedenster Betriebssystem- und Browserversionen an. Die Tests in der Sauce Cloud auszuführen, ist dabei auch extrem einfach, man benötigt nur einen Sauce-Labs-Account, installiert das dalek-driver-sauce-Plug-in via npm und hinterlegt alle relevanten Daten in seiner Dalekfile.json-Konfigurationsdatei. Wie das genau funktioniert, entnimmt man am besten der Dokumentation des Plug-ins auf der Dalek-Homepage. Ein besonderes Schmankerl bietet Sauce Labs für die Maintainer von Open-Source-Projekten: Sind die Tests öffentlich zugänglich, zum Beispiel in einem GitHub Repo, ist der Service kostenlos nutzbar.

Abb. 3: Remote Testing Service von Sauce Labs

Schlusswort

Nachdem wir jetzt im Schnellgang durch die Basics von Dalek und automatisiertem Testing marschiert sind, können wir das Gelernte nun in der Dokumentation weiter vertiefen. Abschließend noch ein Wort der Warnung: DalekJS ist ein Prototyp – eine Developer-Preview, wie man so gerne sagt. Es ist jung, es hat Bugs und der eine oder andere davon kann einen schon mal verzweifeln lassen. Außerdem wird sich das API ändern. Nun gut, ich will niemanden abschrecken. Probiert es aus. Findet Bugs, schreibt Issues auf GitHub, oder noch besser: Schickt Pull Requests. Daleks haben in den vergangenen Jahrzehnten mit einem echten Imageproblem kämpfen müssen, aber eines Tages werden sie hoffentlich auch in euer Entwicklungsteam einfallen und besseres, bugfreieres Internet für uns alle schaffen.

Best Practices Die beste Technik nützt nichts, wenn sie nicht gut eingesetzt wird. Gerade in agilen Projekten ändert sich der Code unserer Applikation sehr schnell. Davon ist meist nicht nur die Applikationslogik betroffen, auch das Markup ändert sich gerne mal von Sprint zu Sprint. Da sich Dalek-Tests nahe am DOM befinden, ist es wichtig, sie so gut wie möglich zu entkoppeln. Dank HTML5 und dem data-*-Attribut, haben wir die Möglichkeit, selbst Marker zu produzieren, mit denen wir DOM-Elemente eindeutig identifizieren können. Unter anderem Xing nutzt diese Technik, um Elemente mit data-qa-Attributen zu versehen und Tests DOM-agnostisch zu halten. Nicht nur in unserer Applikation, auch in Tests ist es wichtig, Code wiederzuverwenden. Dalek selbst implementiert keine eigene Logik, um zum Beispiel etwas wie Page Objects aus der Selenium-Welt nachzubilden. Man kann sich allerdings der Macht der Node.js-require-Funktion bedienen, um Codeschnipsel in mehreren Tests wiederzuverwenden. Wie das geht, zeigt das Gist hier. Zu guter Letzt noch ein Ratschlag: Es ist nicht sinnvoll, alles zu testen, was geht. Gerade Textinhalte verleiten schnell dazu, Tests für Content zu schreiben. Doch der Content unterliegt zumeist nicht der Herrschaft des Entwicklers und ändert sich oft durch den Eingriff Dritter. Dies führt im Endeffekt dazu, dass Tests fehlschlagen und man als Entwickler viel mehr mit Wartungsarbeiten an den Tests beschäftigt ist, als damit, wichtigere Aufgaben zu vollführen. Es ist ratsam, klein anzufangen, die kritischen Elemente der Applikation oder Seite abzusichern und dort Gründlichkeit walten zu lassen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -