Hinweis:
Dieser Blogartikel ist älter als 5 Jahre – die genannten Inhalte sind eventuell überholt.
Nachdem mit Polymer 1.0 eine stabile Basis für produktive Anwendung der Bibliothek geschaffen wurde, ist es die Top-Priorität des Entwickler:innen-Teams, das Tooling rund um Polymer zu verbessern, damit Polymer nicht nur theoretisch, sondern auch praktisch zur Entwicklung von modernen Webapps eingesetzt wird. Dabei stehen generell nicht nur Entwicklungsgeschwindigkeit und Performance sondern auch die Wiederverwendbarkeit und korrekte Dokumentation von selbst erstellen Komponenten im Fokus.
In diesem Artikel wird gezeigt, welche Tools, die den Gebrauch von Polymer im Entwickler:innen-Alltag vereinfachen, heute schon bereitstehen oder sich in der aktiven Entwicklung befinden. Dabei wird ein prototypischer Workflow mit Build-Chain anhand der verfügbaren Werkzeuge skizziert, um einen Ausblick auf die zukünftigen Möglichkeiten zu geben.
Getting started
Damit die Entwicklung von eigenen Projekten mithilfe von Polymer auch für Anfänger möglichst einfach ist, hat das Polymer-Team das „Polymer Starterkit“ ins Leben gerufen. Dabei handelt es sich um eine Projektvorlage/ein Template, das eine funktionierende Entwicklungsumgebung bereitstellt, mit der direkt losgelegt werden kann. Zuvor muss allerdings die Node.js-Laufzeitumgebung und das als Build-System verwendete Gulp installiert werden. Als Dependency-Manager wird Bower eingesetzt. Die Vorlage beinhaltet nicht nur die Entwicklungsumgebung sondern auch ein kleines Beispielprojekt, das die verschiedenen Features aufzeigt und ein guter Startpunkt für ein eigenes Projekt ist. Beispielsweise ist ein Router-Element und ein rudimentäres Layout auf Basis von Paper-Elementen bereits inkludiert.
Zum Erzeugen eines neuen Projekts auf Basis des Polymer Starterkit kann entweder die Zip-Datei des neuesten Releases heruntergeladen und entpackt oder das Scaffolding-Tool Yeoman genutzt werden. Für Yeoman gibt es den Polymer-Generator, welcher die Installation des Starterkits und seiner Abhängigkeiten übernimmt.
Das Einrichten mithilfe von Yeoman funktioniert folgendermaßen:
|
1 2 3 |
npm install -g yo@1.4.8 && npm install -g generator-polymer@1.2.1 yo polymer:app |
Ohne Yeoman müssen die Abhängigkeiten von Hand installiert werden:
|
1 2 3 4 5 |
#laden und entpacken von polymer-starter-kit.zip npm install #installation der entwicklungsumgebung bower install #download der abhängigkeiten |
Nach dem Einrichten des Starterkits kann mit dem Befehl „gulp serve“ ein Entwicklungs-Webserver gestartet werden, der die Web-App zu Testzwecken anzeigt. Um die Feedback-Schleife während des Entwickelns möglichst kurz zu halten, horcht gulp auf Datei-Änderungen und lädt bei Bedarf die Web-App im Browser neu.
Der mit gulp realisierte Build-Prozess führt folgende Schritte aus:
- Optimieren von Bildern und Fonts
- Minifizieren von Stylesheets, Skripten und HTML-Code
- Konkatenation aller verwendeten Komponenten in eine einzelne HTML-Datei
Zusätzlich wird Javascript-Code mithilfe von JSHint auf mögliche Fehler untersucht. Im Kapitel „Deployment-Build“ werden die Besonderheiten des Prozesses genauer erklärt.
Mit „gulp test“ können die Unit-Tests der selbst erstellten Komponenten mit dem Web Component Tester ausgeführt werden.
Testen mit WCT
Wie jeder Code sollten mit Polymer erstellte Web Components vor dem Release gründlich getestet werden. Die „Unit“, die sich im Falle Polymer anbietet, ist die einzelne Komponente. Die Tests für eine Komponente werden dabei in einer HTML-Datei gekapselt:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
In dieser Vorlage werden der Webcomponent-Polyfill, der Testrunner und die zu testende Komponente geladen. Im body wird das zu testende Element angelegt. Die Tests selbst stehen dann in einem script-Tag, das auf das Element folgt:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
suite, test und assert sind Methoden des Testframeworks mocha.js, die automatisch mit dem Web Component Tester (kurz WCT genannt) geladen werden. Mit ihnen ist es nun möglich, Unit-Tests zu formulieren. Diese werden vom Kommandozeilen-Client „wct“ ausgeführt, und zwar in allen installierten Browsern, für die Treiber zur Automatisierung vorhanden sind. Zur Fernsteuerung der Browser setzt der WCT Selenium ein.
Leaky State verhindern
Ein Problem, das beim oben gezeigten Beispiel auftritt, ist der sog. Leaky State – das zu testende Element wird für die einzelnen Tests nicht zurückgesetzt, es behält also seinen internen Zustand, z.B. geladene Daten oder Einstellungen. Dadurch kann ein Testfall einen anderen beeinflussen und die Tests können beispielsweise nicht mehr in beliebiger Reihenfolge ausgeführt werden. Nun wäre es natürlich möglich, das Element vor jedem Test zurückzusetzen. Doch wie es so oft im Polymer-Umfeld heißt: „There is a component for that“. In diesem Fall heißt die erforderliche Komponente test-fixture und kümmert sich darum, dass jeder Test mit exakt den selben Bedingungen startet:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |