17. Aug 2020
Lesedauer 13 Min.
Ein Tool, um alle zu testen
Cross Browser Testing mit BrowserStack, Teil 1
Sollen Webanwendungen verschiedene Browser und Geräte unterstützen, muss dies für alle Browser-Geräte-Kombinationen getestet werden. BrowserStack kann dabei helfen.
Unter Cross Browser Testing versteht man das Testen einer Webanwendung über mehrere Browser (und Plattformen) hinweg. Dies hat das Ziel, die Kompatibilität und Bedienbarkeit in den verschiedenen Umgebungen sicherzustellen. Insbesondere bei responsiven Webseiten können sich dabei große Unterschiede in der Darstellung ergeben, welche vor allem durch den verwendeten Browser, dessen Version, das Betriebssystem und dessen Version sowie das Endgerät und seine Auflösung bedingt sind.Um browserübergreifend zu testen, werden Tests herangezogen, welche automatisiert auf echten Remote-Geräten oder -VMs ausgeführt werden. Diese Tests sollten typische Anwendungsfälle eines Benutzers und seiner Interaktion mit der Anwendung abbilden, einschließlich Klicks auf Buttons, Eingaben in Input-Felder, Scrolling und Navigieren zwischen Seiten et cetera. Tests dieser Art komplett selbst zu realisieren ist sehr aufwendig und komplex, weshalb es sich anbietet, auf Standardsoftware zurückzugreifen, die dabei unterstützt. Damit ergibt sich neben der Zeitersparnis auch eine Kostenersparnis, weil keine Endgeräte gekauft, gepflegt beziehungsweise emuliert werden müssen.Welche Kombinationen aus Browsern, Betriebssystemen und Endgeräten man testet, richtet sich danach, mit welcher Auswahl ein Großteil der eigenen Benutzergruppen abgedeckt ist. Dabei ist es hilfreich, bereits etwas über die eigenen Anwender zu wissen, beispielsweise durch Auswertung von Server-Logs oder Trackingdaten. Wird die Anwendung nur sporadisch von Nutzern mit Mobilgeräten besucht, lohnt sich der Aufwand eventuell nicht. Ähnlich verhält es sich mit dem Support für exotische Browser oder ältere Browserversionen der bekannteren Vertreter.
Testarten
Wenn im Zusammenhang mit Cross Browser Testing von Tests die Rede ist, so sind damit Ende-zu-Ende-Tests (E2E-Tests) gemeint. Darunter versteht man Tests, bei denen der echte UI-Teil der Anwendung herangezogen wird. Kombiniert man diesen mit Mocks für das Backend (und gegebenenfalls für weitere angeschlossene Systeme), spricht man von UI-Integrationstests; verwendet man hingegen reale Systeme, ist von System-Integrationstests die Rede. Beide Testarten können im Zusammenspiel mit BrowserStack verwendet werden, jedoch ist es häufig zielführender, sich auf UI-Integrationstests zu beschränken, da die korrekte Darstellung im Vordergrund steht. Drittsysteme haben darauf meist keinen großen Einfluss, womit man sich deren Integration ins Testsetup sparen kann. Komponenten einer Anwendung (Units) sind in der Regel unabhängig vom verwendeten Browser und müssen daher nicht browserübergreifend getestet werden.
Dieser Artikel stellt das Tool BrowserStack vor, das dabei hilft, browserübergreifende E2E-Tests zu realisieren (vergleiche Kasten Testarten). Im ersten Teil wird zunächst ein Beispielprojekt konfiguriert, anhand dessen die Verwendung von BrowserStack demonstriert werden soll. Im zweiten Teil des Beitrags werden dann Testfälle erstellt, um die neu erstellte Konfiguration auch zum Einsatz bringen zu können.
Was ist BrowserStack?
BrowserStack ist ein seit 2011 existierender Anbieter für Cloud-, Web- und Mobile-Testdienste. Das in Mumbai ansässige Unternehmen bietet vier Produkte an, die als Software as a Service (SaaS) zur Verfügung gestellt werden. Diese sind „Live“ und „Automate“, die für Tests von Webanwendungen in verschiedenen Browsern vorgesehen sind, sowie „App Live“ und „App Automate“ zum Testen von mobilen Apps. Die Preise für die Nutzung der Dienste variieren je nach der Zahl der Nutzerlizenzen, der Menge parallel ausführbarer Testinstanzen und den beinhalteten Teildiensten. Bei jährlicher Zahlung kostet die Nutzung von Live mit einer Testsession und einem Nutzer 29 US-Dollar pro Monat. Für Automate beginnen die Preise bei 129 US-Dollar, für Automate Mobile bei 199 Dollar. In beiden Fällen erhält man eine Testsession mit unbegrenzt vielen Nutzerzugängen. Jedes größere Paket enthält dabei stets auch die Funktionen des nächstkleineren. Für Geschäftskunden, Freiberufler und Open-Source-Projekte bietet das Unternehmen dedizierte Preismodelle an. Zudem ist eine kostenlose Probemitgliedschaft möglich, die ein Testkontingent von 30 bis 100 Minuten für jeden Teildienst enthält. Der Fokus dieses Beitrags wird auf den Teildiensten Live und Automate liegen.BrowserStack Live
Live erlaubt das interaktive Testen von Webanwendungen auf echten Remote-Geräten. Dabei gibt es eine Vielzahl möglicher Kombinationen aus Betriebssystemen und Browsern, jeweils in verschiedenen Versionen. Unterstützte Betriebssysteme sind Android, iOS, Windows und macOS (Bild 1).
Das Dashboardvon BrowserStack Live(Bild 1)
Autor
Welche Browser zum Testen mit Live gewählt werden können, ergibt sich aus dem gewählten Betriebssystem. Neben den herstellergebundenen Browsern (IE und Edge bei Microsoft / Safari bei Apple) wird stets Chrome angeboten. Je nach Plattform sind meist noch Firefox (Windows, macOS, Android) und Opera (Windows, macOS) verfügbar. Eine genaue Aufschlüsselung enthält die Dokumentation des Anbieters [1].Mit Live lassen sich sowohl lokal gehostete Anwendungen ansteuern als auch öffentlich erreichbare Seiten testen. Für Letztere muss nichts weiter getan werden, man kann direkt mit der Nutzung des Dienstes beginnen.Um lokale Anwendungen testen zu können, muss zusätzlich das Browser-Plug-in „BrowserStack Local“ installiert werden, das für Chrome im Chrome Web Store [2] zur Verfügung steht. Die Funktionsweise des „Local Testing“ wird im folgenden Abschnitt zu Automate noch genauer erläutert.Mit BrowserStack Live lassen sich die Auswirkungen von Codeänderungen auf die Darstellung der Anwendung sofort überprüfen. Bei Kundenprojekten bietet sich Live somit auch als Möglichkeit zum Nachtest für den QA-Kollegen oder zur Abnahme für den Kunden an. Auch das Wechseln zwischen Endgeräten ist möglich und dauert meist nur einige Sekunden. Auf Geräten, die Chrome als Browser nutzen, stehen dem Nutzer die Entwicklerwerkzeuge zur Verfügung, wie man sie aus dem Desktopbrowser kennt, was das Debugging im Einzelfall deutlich erleichtern kann. Weitere Features wie die Simulation ausländischer IP-Adressen (Geolocation) und verschiedener Bildschirmauflösungen können bei entsprechenden Anwendungsfällen von Vorteil sein. Die Integration mit GitHub, Trello, Jira und Slack hilft, Fehler, die beim Testen mit Live gefunden wurden, direkt an das jeweilige Tool zu reporten.
BrowserStack Automate
Mit Automate lassen sich E2E-Tests auf Basis von Selenium automatisiert und je nach Lizenz parallelisiert auf verschiedenen Browsern und Geräten ausführen. Hierbei ist es in der Regel möglich, bereits vorhandene Testfälle wiederzuverwenden. Dabei sind einige Browser beziehungsweise deren Webdriver fehlertoleranter als andere; gegebenenfalls müssen kleinere Anpassungen getätigt werden. So ist es beispielsweise notwendig, beim Testen mit IE 11 vor der Ausführung einer Testaktion (zum Beispiel Klick auf Button Hinzufügen) sicherzustellen, dass das jeweilige Element in diesem Moment im Viewport liegt. Ist dies nicht der Fall, schlägt der Test fehl, ohne dass der Grund dafür aus dem zugehörigen Log hervorginge. Neben derartigen Eigenarten einzelner Browser ist der Großteil der möglichen Ursachen für Testfehler berechtigter Natur. So kann zum Beispiel im Kontext von Mobilgeräten leicht der Fall auftreten, dass ein zu klickendes Element von einem anderen Element überlagert wird oder eine Testaktion nicht durchgeführt werden kann, weil eine vorangegangene Aktion fehlgeschlagen ist.Um solchen Fehlern auf den Grund zu gehen, existiert das BrowserStack-Automate-Dashboard (Bild 2). Hier findet sich zunächst eine Übersicht aller absolvierten Testdurchläufe. Wählt man einen einzelnen Testdurchlauf aus, stehen neben Eckdaten wie Session-ID, Gerät, Betriebssystem und Testlaufzeit auch zahlreiche Optionen zum Debugging bereit. Allen voran steht dabei die Video-Option. Ist diese codeseitig aktiviert, wird die Testausführung auf dem jeweiligen Endgerät aufgezeichnet und steht danach als Video zur Verfügung. Das erlaubt dem Entwickler einen schnellen Abgleich der angedachten Testschritte mit dem, was faktisch in der jeweiligen Testumgebung passiert, wodurch sich Fehler schneller identifizieren lassen.
Das Automate-Dashboardmit Video-Option(Bild 2)
Autor
Darüber hinaus bietet das Dashboard verschiedene Log-Arten, namentlich Text Logs, Console Logs, Network Logs und Selenium Logs. Per Default werden nur Text Logs generiert, die anderen Logs müssen bei Bedarf per Konfiguration aktiviert werden. Normalerweise ist die Text-Log-Option völlig ausreichend, da hier die wichtigsten Testereignisse in Textform dokumentiert und im Fehlerfall automatisiert Screenshots erstellt werden. Praktisch: Bei jedem Ereignis wird die passende Stelle im Video verlinkt, sodass man die Auswirkungen einer bestimmten Aktion direkt visuell abgleichen kann. Erwähnt sei noch, dass die anderen Log-Arten vor allem dann interessant sind, wenn es um die Analyse struktureller Probleme im Umgang mit BrowserStack geht. Falls Netzwerk- oder Verbindungsprobleme für Fehlschläge sorgen, ist der Kontakt zum Support meist unumgänglich. Dieser benötigt dann die entsprechenden Session-IDs und insbesondere die Daten des Network Log für die Ursachenforschung.Analog zu Live ist es möglich, sowohl öffentlich zugängliche Webseiten als auch lokal deployte Umgebungen zu testen. Letzteres können neben lokal gehosteten Seiten zum Beispiel auch Staging-Umgebungen, einzelne HTML-Dateien oder im eigenen Netzwerk gehostete Seiten sein. Für lokales Testen wird die Anwendung BrowserStack Local benötigt. Die Anwendung baut eine sichere Verbindung (Tunnel) zwischen der lokalen Umgebung und dem BrowserStack-Server auf. Dadurch können Anfragen während der Testausführung zwischen der lokal gehosteten Anwendung im privaten Netz und dem BrowserStack-Server im öffentlichen Netz ausgetauscht werden (Bild 3).
Schaubild der Funktionsweisevon lokalem Testen(Bild 3)
BrowserStack [9]
Setup Minimalprojekt, Konfiguration und Ausführung
Um die Funktionen von BrowserStack auch praktisch zu sehen, wird ein Beispielprojekt benötigt. Der Einfachheit halber wurde das in der Angular-Community weithin bekannte Beispiel der „Tour of Heroes“ [3] von John Papa gewählt. Für die Installation wird eine aktuelle Version von Node.js mit NPM benötigt. Da das Beispiel in seiner Originalversion auf Angular 6 basiert, welches noch auf Version 8 von Node aufbaut (deren Support 2019 endete), müssen zunächst die Dependencies des Projekts aktualisiert werden. Hierbei kann aufgrund der Einfachheit des Beispielprojekts überall die aktuelle Version herangezogen werden.Zusätzlich muss wegen der neueren Version von core-js eine kleine Anpassung in der Datei polyfills.ts im src-Ordner des Projekts vorgenommen werden:
import 'core-js/es6/reflect';
import 'core-js/es7/reflect';
Diese Zeilen werden geändert zu:
import 'core-js/features/reflect';
Alternativ findet sich in dem Repository unter [4] eine Version des Projekts, bei der diese Anpassungen bereits durchgeführt wurden.Zum Start sollte das Repository heruntergeladen oder geklont werden. Danach kann das Projekt installiert werden:
npm install
Das für E2E-Tests im Angular-Umfeld häufig verwendete Framework Protractor ist bereits im Projekt enthalten, für die Ausführung von E2E-Tests mit BrowserStack Automate muss lediglich die entsprechende Bibliothek [5] hinzugefügt werden:
npm install browserstack-local
Bevor wir nun tiefer in die Konfiguration für „Automate“ einsteigen, soll ein kurzer Blick auf BrowserStack Live geworfen werden. Hierzu muss die Anwendung gestartet werden:
npm run start
War der Aufruf erfolgreich, ist die Anwendung im Browser unter der Adresse localhost:4200 aufrufbar (Bild 4).
Die „Tour of Heroes“-Anwendung(Bild 4)
Autor
Möchte man die Anwendung nun in BrowserStack Live betrachten, so muss dafür Chrome mit dem bereits erwähnten Plug-in Browserstack Local verwendet werden. Steuert man in dieser Konfiguration live.browserstack.com an, gelangt man zum Live-Dashboard und kann eine Browser-Geräte-Kombination auswählen, woraufhin die entsprechende Kombination im Chrome geladen wird. Im nun angezeigten Browser innerhalb des Remote-Geräts kann, analog zu vorher, die Adresse localhost:4200 eingegeben werden, und die lokal gehostete Anwendung wird im Remote-Gerät dargestellt (Bild 5).
Lokale Anwendungin einem Google Pixel 4 in BrowserStack Live(Bild 5)
Autor
Sollte es Probleme bei der Darstellung geben, ist zu prüfen, ob der Farbindikator neben der Schaltfläche Local Testing in Grün (statt in Rot) dargestellt wird. In diesem Fall liegt in der Regel ein Problem mit der Verbindung zum Local-Plug-in vor. Eine weitere Besonderheit stellen iOS-Geräte dar, da diese nicht via localhost erreichbar sind. Diese werden stattdessen per bs-local.com:PORT angesteuert, jedoch ist dies mit Anpassungen an der Projektkonfiguration verbunden, die wir im anschließenden Konfigurationsteil noch vornehmen werden.
Projektkonfiguration
Nachdem das Projekt samt der BrowserStack Local Library installiert ist, sollen nun die Bedingungen geschaffen werden, um automatisiert E2E-Tests mit BrowserStack Automate ausführen zu können. Hierfür verwendet unser Beispielprojekt das Framework Protractor. Für gewöhnliche, lokal ausgeführte E2E-Tests braucht Protractor eine eigene Konfigurationsdatei namens protractor.conf.js, welche im Projekt bereits vorhanden ist. Sie enthält hauptsächlich Einstellungsparameter, die das Framework zur Ausführung benötigt. Für die Ausführung unserer E2E-Tests auf BrowserStack benötigen wir ebenfalls eine solche Konfigurationsdatei, jedoch mit einigen zusätzlichen Anpassungen für die BrowserStack-Umgebung. Daher erstellen wir zunächst eine Kopie der protractor.conf.js im Root-Verzeichnis des Projekts und ändern deren Namen in protractor.browserstack.conf.js. Im Folgenden werden wir die Datei Stück für Stück erweitern. An dieser Stelle sei gesagt, dass es dabei nicht den einen richtigen Weg gibt. Vielmehr geben die Dokumentationen von Protractor [6] und BrowserStack Local [7] einen gewissen Grundaufbau vor, doch lässt sich die Konfiguration je nach Anforderung unterschiedlich erweitern. Hier wollen wir uns auf die grundlegenden Dinge beschränken. Dafür importieren wir als Erstes die Bibliothek browserstack-local:
const browserstack = require('browserstack-local');
Darunter legen wir eine Variable mit einem Objekt an, in dem allgemeine Einstellungsparameter für die Ausführung in BrowserStack gespeichert sind (Listing 1).
Listing 1: Objekt mit BrowserStack-Einstellungen
const browserstackCapabilities = { <br/> project: 'Tour of Heroes Browserstack Test', <br/> 'browserstack.local': 'true' <br/> 'browserstack.timezone': 'UTC', <br/> 'browserstack.video': 'true', <br/> 'browserstack.debug': 'false', <br/> 'browserstack.networkLogs': 'false', <br/> 'browserstack.user': 'bsuser123', <br/> 'browserstack.key': 'bskey123' <br/>};
Die meisten Einstellungen sind selbsterklärend. Obligatorisch ist hier nur die Angabe von browserstack.user und browserstack.key. Die zugehörigen Werte können statt im Klartext auch als Systemumgebungsvariablen hinterlegt und darüber aufgerufen werden:
'browserstack.user':
process.env.BROWSERSTACK_USERNAME,
'browserstack.key':
process.env.BROWSERSTACK_KEY
Das Setzen der Werte über Umgebungsvariablen kann in Projekten mit mehreren Entwicklern notwendig sein, um die Testdurchläufe voneinander unterscheiden zu können. Darüber hinaus ist es aber auch bei Verwendung von CI/CD-Servern hilfreich, da somit die relevanten Parameter für diese separat gesetzt werden können.Die anderen Optionen wie debug- und networkLog sind optional, doch lohnt es sich, diese ebenfalls im Objekt zu verwalten für den Fall, dass es im Rahmen des Debuggings notwendig wird, diese Logs zu aktivieren, denn defaultmäßig werden diese nicht mitgeschrieben.Als Nächstes passen wir das aus der protractor.conf.js übernommene config-Objekt an. Den Wert für allScriptsTimeout, der angibt, wie viel Zeit jedem Skript zur Ausführung im Browser zur Verfügung steht, erhöhen wir von 11 000 auf 60 000 Millisekunden. Darunter ergänzen wir getPageTimeout: 30000, um ein Maximum von 30 Sekunden für die Ladezeit der Seite zu definieren.Der Wert für specs gibt den Pfad zu den E2E-Testdateien an. Im Original des „Tour of Heroes“-Projekts liegen im angegebenen Ordner e2e sowohl Testdateien als auch Page-Objects. Was sich dahinter verbirgt, wird später noch deutlich. Das kann schnell unübersichtlich werden, daher erstellen wir im e2e-Ordner zwei Unterordner, page-objects und specs, und verschieben die vorhandenen Dateien app.po.ts und app.e2e-spec.ts in das jeweilige Verzeichnis (Bild 6).
Die Dateistrukturdes e2e-Ordners(Bild 6)
Autor
In app.e2e-spec.ts müssen wir zusätzlich den Importpfad in Zeile 1 an die neue Struktur anpassen:
import { BlankPage } from '../page-objects/app.po';
Anschließend wechseln wir zurück in protractor.browserstack.conf.js und ändern den Pfad von specs:
specs: ['./e2e/specs/*.e2e-spec.ts'],
Die vorhandene Property capabilities wird samt ihrem zugehörigen Wert entfernt und ersetzt durch:
multiCapabilities: []
In das leere Array der neuen Property multiCapabilities setzen wir später die Werte der zu testenden Browser-Geräte-Kombinationen ein. Die Properties directConnect und baseUrl werden entfernt und es kommen mit seleniumAddress und maxSessions zwei neue hinzu:
seleniumAddress: 'http://
hub-cloud.browserstack.com/wd/hub'
maxSessions:
Number(process.env.BROWSERSTACK_
SESSION_COUNT || 2),
In seleniumAddress wird die Adresse des von BrowserStack genutzten Selenium-Servers gesetzt, maxSessions begrenzt die parallel ausgeführten Webdriver-Instanzen. Der Rest des config-Objekts bleibt unverändert.Nun fehlt noch das Starten der BrowserStackLocal-Instanz vor dem Test sowie das Beenden nach Abschluss des Tests. Das Starten erfolgt in Protractors Methode onPrepare(), wie in Listing 2. Das Beenden der BS-Local-Instanz nach Abschluss des Testens erfolgt in der Methode afterLaunch():
Listing 2: Die beforeLaunch-Konfiguration
beforeLaunch() { <br/> return new Promise((resolve, reject) =&gt; { <br/> console.log('Connecting local'); <br/> exports.bs_local = new browserstack.Local(); <br/> exports.bs_local.start( <br/> { <br/> key: browserstackCapabilities['browserstack.key'] }, <br/> function(error) { <br/> if (error) return reject(error); <br/> console.log('Connected. Now testing...'); <br/> resolve(); <br/> } <br/> ); <br/> }); <br/>},
afterLaunch() {
return new Promise(resolve =>
exports.bs_local.stop(resolve));
}
Was jetzt noch fehlt, sind die zu testenden Kombinationen aus Geräten und Browsern. BrowserStack stellt hierfür den Capability Generator [8] zur Verfügung. Dort kann man sich für verschiedene Sprach-Bindings die gewünschten Browser-Geräte-Kombinationen zusammenklicken; es gibt aber auch eine genaue Dokumentation der Parameter, die in die Konfiguration einfließen können. Darunter sind außer den bereits bekannten, BrowserStack- oder testspezifischen Schlüsseln wie browserstack.user oder browserstack.video auch viele browserspezifische Einstellungen wie die Treiberversion (Chrome Driver, Gecko Driver et cetera) oder der Umgang mit Pop-ups beim Testen. Auch für Mobilgeräte stehen Einstellungsmöglichkeiten wie Bildschirmorientierung oder simulierte Netzwerkgeschwindigkeiten bereit. In der Regel reicht es jedoch, mit den vom Capability Generator ausgegebenen Werten zu arbeiten und Änderungen nur im Rahmen der Fehlerbehebungen oder für spezielle Anwendungsfälle durchzuführen. Für unser Beispielprojekt wollen wir vier verschiedene Kombinationen testen, je zwei Desktop- und zwei Mobilgeräte:
- Firefox 74 auf Windows 10
- Safari 11 auf OS X High Sierra
- Chrome Mobile auf einem Galaxy Note 10
- Safari Mobile auf einem iPhone X
Listing 3: Beispiel Browsercapability
var capabilities = { <br/> "os": "Windows", <br/> "os_version": "10", <br/> "browserName": "Firefox", <br/> "browser_version": "74.0", <br/> "browserstack.local" : "false", <br/> "browserstack.selenium_version" : "3.10.0", <br/> "browserstack.user": "USERNAME", <br/> "browserstack.key": "ACCESS_KEY" <br/>}
Bevor wir dieses Objekt nun in unser multiCapabilities-Array einfügen, entfernen wir alle Angaben, die wir bereits in browserstackCapabilities pflegen, und holen uns dessen Inhalt mithilfe des spread-Operators in das Capability-Objekt.Dies tun wir für alle vier Testgeräte. Bei den mobilen Geräten muss der Wert für browserName eventuell von Hand angepasst werden. Beim iPhone wird aus “iPhone“ dann “Safari“, für das Galaxy-Gerät wird “Android“ zu “Chrome“. Zudem sollte für jedes Gerät die Property logName ergänzt werden, um sie in den Logausgaben identifizieren zu können. Das ergibt eine Konfiguration wie in Listing 4.
Listing 4: Fertige Protractor-Konfiguration für BrowserStack (Teil 1)
const { SpecReporter } = <br/> require('jasmine-spec-reporter'); <br/>const browserstack = require('browserstack-local'); <br/><br/>const browserstackCapabilities = { <br/> project: 'Tour of Heroes Browserstack Test', <br/> 'browserstack.local': 'true', <br/> 'browserstack.timezone': 'UT', <br/> 'browserstack.video': 'true', <br/> 'browserstack.debug': 'false', <br/> 'browserstack.networkLogs': 'false', <br/> 'browserstack.user': 'bsuser123', <br/> 'browserstack.key': 'bskey123' <br/>}; <br/><br/>exports.config = { <br/> allScriptsTimeout: 300000, <br/> getPageTimeout: 30000, <br/> specs: ['./e2e/specs/*.e2e-spec.ts'], <br/> seleniumAddress: 'http://hub-cloud.browserstack.com/<br/> wd/hub', <br/><br/> multiCapabilities: [ <br/> { <br/> logName: 'Windows 10 Firefox', <br/> os: 'Windows', <br/> os_version: '10', <br/> browserName: 'Firefox', <br/> browser_version: '74.0', <br/> 'browserstack.selenium_version': '3.10.0', <br/> ...browserstackCapabilities <br/> }, <br/> { <br/> logName: 'OSX Safari', <br/> os: 'OS X', <br/> os_version: 'High Sierra', <br/> browserName: 'Safari', <br/> browser_version: '11.0', <br/> ...browserstackCapabilities <br/> }, <br/> { <br/> logName: 'Galaxy Note 10 Chrome', <br/> os_version: '9.0', <br/> device: 'Samsung Galaxy Note 10', <br/> browserName: 'Chrome', <br/> real_mobile: 'true', <br/> ...browserstackCapabilities <br/> }, <br/> { <br/> logName: 'iPhone X Safari', <br/> device: 'iPhone X', <br/> os_version: '11', <br/> browserName: 'Safari', <br/> real_mobile: 'true', <br/> ...browserstackCapabilities <br/> } <br/> ], <br/> maxSessions: Number(<br/> process.env.BROWSERSTACK_SESSION_COUNT || 2), <br/><br/> framework: 'jasmine', <br/> jasmineNodeOpts: { <br/> showColors: true, <br/> defaultTimeoutInterval: 30000, <br/> print: function() {} <br/> }, <br/><br/> beforeLaunch() { <br/> return new Promise((resolve, reject) =&gt; { <br/> console.log('Connecting local'); <br/> exports.bs_local = new browserstack.Local(); <br/> exports.bs_local.start( <br/> { <br/> key: browserstackCapabilities['browserstack<br/> .key'] <br/> }, <br/> function(error) { <br/> if (error) return reject(error); <br/> console.log('Connected. Now testing...'); <br/> resolve(); <br/> } <br/> ); <br/> }); <br/> }, <br/><br/> async onPrepare() { <br/> require('ts-node').register({ <br/> project: 'e2e/tsconfig.e2e.json' <br/> }); <br/> jasmine.getEnv().addReporter(new SpecReporter({ <br/> spec: { displayStacktrace: true } })); <br/><br/> return browser.getProcessedConfig(); <br/> }, <br/><br/> afterLaunch() { <br/> return new Promise(resolve =&gt; <br/> exports.bs_local.stop(resolve)); <br/> } <br/>};
Die Konfigurationsdatei für die Ausführung der E2E-Tests ist damit fertig. In einem vorletzten Schritt müssen wir in der Datei angular.json im Rootverzeichnis im Abschnitt serve und dort unter configurations Folgendes einfügen:
"browserstack": {
"publicHost": "bs-local.com:4200"
}
Nun ergänzen wir im Abschnitt tour-of-heroes-e2e unter e2e unmittelbar nach dem options-Objekt ein weiteres Objekt:
"configurations": {
"browserstack": {
"devServerTarget": "tour-of-heroes:serve:browserstack"
}
}
Ohne diese Änderungen würden Anfragen stets an localhost:4200 gerichtet werden, was meist kein Problem ist. Laut BrowserStack existieren in Safari jedoch Einschränkungen, die ein Umleiten der Anfragen an bs-local.com notwendig machen. Die Funktionalität in den anderen Browsern wird dadurch nicht beeinflusst. Zuletzt müssen wir unsere neu erstellte Protractor-Konfiguration und die hinzugefügte E2E-Konfiguration noch per NPM-Skript einbinden. Dazu fügen wir im Abschnitt scripts der Datei package.json folgende Zeile hinzu:
"e2e-bs": "ng e2e --configuration=browserstack
--protractorConfig=./protractor.browserstack.conf" Fazit
Die Konfiguration unseres Beispielprojekts steht nun. Im zweiten Teil des Artikels werden wir Testfälle erstellen und BrowserStack dann auch tatsächlich zum Einsatz bringen.Fussnoten
- BrowserStack, Browsers & Mobile Devices for Live Testing, http://www.dotnetpro.de/SL2009BrowserStack1
- BrowserStack Local, http://www.dotnetpro.de/SL2009BrowserStack2
- Tour of Heroes, http://www.dotnetpro.de/SL2009BrowserStack3
- Tour of Heroes updated, http://www.dotnetpro.de/SL2009BrowserStack4
- NPM, browserstack-local-nodejs, http://www.dotnetpro.de/SL2009BrowserStack5
- Protractor, http://www.dotnetpro.de/SL2009BrowserStack6
- BrowserStack Local, Dokumentation, http://www.dotnetpro.de/SL2009BrowserStack7
- Capability Generator, http://www.dotnetpro.de/SL2009BrowserStack8
- https://www.youtube.com/watch?v=znWhn1FvHl8, https://www.youtube.com/watch?v=znWhn1FvHl8
