Früher oder später findet man als macOS Nutzer etwas, für das man ganz dringend Windows braucht. Die Alternativen für Mac sind entweder nicht gut genug, teuer oder gar nicht existent.
Ich muss gestehen, dass es bei mir in erster Linie ein Spiel war, das nicht für meinen Mac verfügbar war. Ich weiß, Schande über mich, dass ich versuche mit einem Mac zu zocken, aber ich habe nun einmal keinen anderen Rechner. Aus Kostengründen versuchte ich es zunächst mit Wine, was allerdings eher einem Glücksspiel glich. Mal funktioniert es, mal nicht. Schon alleine um Steam zu installieren, brauchte es drei verschiedene Programme von Wine, die abwechselnd funktionierten oder gar nicht erst starteten. Irgendwann vergeht einem dann die Lust. Also schaffte ich mir Parallels an.
Parallels hat den Vorteil, dass macOS ganz bequem im Hintergrund laufen kann und nicht alle Aktionen in Windows ausgeführt werden müssen. Die Installation ist einfach, die Nutzung simpel und man kann sogar von Windows auf macOS-Dateien zugreifen und umgekehrt. Einziger Nachteil: man sollte einen Mac mit mindestens 8GB RAM haben, wenn man vernünftig damit arbeiten möchte. Es laufen eben zwei Betriebssysteme gleichzeitig, die sich den RAM teilen. Ein weiterer Nachteil, der für die meisten vielleicht unerheblich ist: Parallels unterstützt kein DirectX11. Da Apple die 3D-Grafikschnittstelle mit der Zeit komplett auf Metal umgestellt hat, funktioniert DirectX11 einfach nicht, wenn macOS im Hintergrund läuft. Was also tun?
Bootcamp heißt die zweite Möglichkeit, um Windows auf dem Mac zu nutzen. Das Einrichten ist etwas komplizierter, der Bootcamp-Installer aber schon auf dem Mac vorinstalliert. Je nach Modell des Macs braucht man einen leeren USB Stick und die ISO der gewünschten Windows Version. Bei neueren Macs läuft die Installation über eine kleine FAT32-Partition, auf die sowohl macOS als auch Windows zugreifen können und ein Stick ist nicht nötig.
Der Nachteil: man muss den Mac jedes Mal neu starten, wenn man Windows nutzen möchte und auf Dateien kann man nur von macOS zugreifen. Benötigt man unter Windows etwas von macOS heißt es neu starten und einen USB Stick suchen, oder einen Cloud-Dienst bemühen.
Zu Beginn der Installation von Bootcamp muss man sich entscheiden, wie groß die Windows-Partition werden soll.
Aber Vorsicht, wenn man auf Parallels nicht verzichten möchte bekommt man hier Probleme. Parallels scheint, was Speicherplatz angeht, ein wenig gierig zu sein. Auf meiner Festplatte waren über 200GB frei, Parallels nahm vom belegten Platz etwa 30GB ein. Trotzdem konnte ich im Bootcamp Installer nur 43GB zur Windows -Partition zuweisen. Zwei Stunden Googeln und einige Wutanfälle später war klar: Parallels reserviert sich den freien Festplattenspeicher vorsorglich. Wird dieser durch Programme oder Dateien unter macOS belegt ist das okay, doch beim Partitionieren der Festplatte legt Parallels Einspruch ein. Immerhin könnte es den Speicher ja irgendwann mal brauchen. Hier hilft dann nur der Verzicht auf Parallels oder das De- und Neuinstallieren, nachdem Bootcamp fertig ist. Backup nicht vergessen!
Lange Rede kurzer Sinn: Je nach Ansprüchen an den Arbeitsprozess können entweder Parallels oder Bootcamp die bessere Wahl sein. Auf beides gleichzeitig sollte man verzichten, es sei denn man stellt sich und seine Nerven auf einige zeitfressende Probleme ein.
An der Uni Köln wird seit mehreren Jahren auf das Content-Managment-System (CMS) TYPO3 gesetzt. Immer mehr Institute und universitäre Einrichtungen greifen dafür auf die TYPO3-Angebote des RRZK zurück, sodass aktuell über 50.000 Seiten, auf über 960 Domains bereitgestellt werden. CMS und Webapplikationen erfordern regelmäßige Wartung und Bugfixes. Jedoch birgt jede Änderung oder Korrektur die Gefahr, dass Nebenwirkungen auftreten und Fehler vielleicht an einer unerwarteten Stelle im System verursacht werden. Regressionstests haben die Aufgabe dies vorzubeugen und Fehler zu finden. Das Ziel lautet: Das, was vorher funktioniert hat, soll auch nach einem Upgrade funktionieren.
Als im vergangenen Sommer die Upgrades unserer Systeme auf die Long Term Support Version v8 des CMS anstanden, haben wir deshalb nach einer Lösung gesucht. Ziel war es ein Programm zu finden, mit der die Front-Ends der Websites auf mögliche “Macken” nach den Upgrades getestet werden können.
Im Web-Bereich wurden in den letzten Jahren einige Libraries und Tools für visuelle Regressionstest entwickelt. Ein visueller Regressionstest führt Front-End- oder User-Interfacetests durch, indem es die Screenshots des User-Interface erfasst und mit den Originalbildern vergleicht. Wenn ein neuer Screenshot vom Referenzscreenshot abweicht, warnt das visuelle Regressionstool.
Visual Regression Testing mit Puppeteer und Resemble.js
Seit 2017 stellt das EntwicklerInnen-Team des Chrome-Browsers mit Puppeteer eine Open-Source Node.js Library bereit, mit welcher ein Chrome Browser ohne eine grafische Oberfläche über eine API angesteuert und automatisiert werden kann. Mittels Puppeteer lassen sich z.B. Screenshots von Websites erstellen aber auch Interaktionen mit dem Front-End einer Website simulieren.
Die mit Puppeteer erstellten Screenshots, gilt es zu vergleichen. Hierfür bietet sich die gut gepflegte Library Resemble.js an. Diese ist darauf spezialisiert Bilddateien abzugleichen und Unterschiede auszugeben.
Teil 1: Screenshots erzeugen
Mit folgenden Tutorial will ich zeigen wie man mit Puppeteer Screenshots mehrerer Seiten erstellt. Ziel ist es am Ende einen Ordner mit Screenshots zu haben, welche anschließend als Ausgangsbilder für Tests dienen werden.
In einem weiteren Artikel werde ich darauf eingehen, wie diese Screenshots mit einem späteren Zustand verglichen werden können.
Vorraussetzung: Zum Ausführen wird die JavaScript Runtime node samt der mitgelieferten Packetverwaltung npm benötigt.
Installationsanleitung für verschiedene Betriebssysteme gibt es auf nodejs.org. Für die Verwendung in Linux-Distributionen bietet NodeSourceRepositories mit kompilierten Binaries an.
Nachdem nun Node.js installiert ist, muss noch ein Ordner erstellt und in das Verzeichnis gewechselt werden:
mkdir puppeteer-resemble-testing
cd puppeteer-resemble-testing
Als nächstes muss ein neues Projekt erstellt werden:
npm init
Für den Zweck dieser Anleitung, kann jede Frage mittels der Return-Taste bestätigt werden. Dabei wird eine neue package.json erstellt.
Nun muss Puppeteer installiert werden:
npm install puppeteer --save
Die Installation kann eine kurze Weile dauern. Denn es wird auch automatisch eine Version von Chromium heruntergeladen und innerhalb des Projekts abgespeichert.
Einzelnen Screenshot erstellen
Puppeteer steht jetzt bereit und kann verwendet werden. Unser erstes Skript erzeugt einen Screenshot der kompletten RRZK-Startseite. Das Ergebnis wird als screenshot.png abgelegt.
Puppeteer hat eine umfassende API-Dokumentation, alle obigen Parameter sind dort ausführlich beschrieben.
Puppeteer ist eine Promise-basierte Bibliothek, in diesem Fall bedeutet dies, dass die Aufrufe an die Chrome-Instanz asynchron durchgeführt werden. Damit der Code des Skript einfach zu lesen ist, wird async/await verwendet. Unsere takeScreenshot()Pfeilfunktion muss deshalb als async definiert werden.
Das Skript wird ausgeführt mit dem Befehl:
node app.js
Im folgenden werden wir auf dieses Skript aufbauen und nach und nach mehr Features hinzufügen.
Mehrere Screenshots in Stapelverarbeitung
Ziel ist es, weiterhin Screenshots vieler Seiten zu erstellen. Um etwas Ordnung zu waren, erstellen wir deshalb zunächst das Unterverzeichnis “screenshots”:
mkdir screenshots
Danach legen wir in app.js ein Array aus Objekten an. In einem Objekt wird jeweils die URL und der Screenshot-Dateiname hinterlegt.
Zum Test kann dieses Array nun durchlaufen werden:
for (const website of websites) {
console.log(website.url)
console.log(website.filename)
}
Beim erneuten Ausführen des Skripts werden nun die Inhalte des websites-Arrays ausgegeben.
Bisher ist in unserer takeScreenshot() Funktion die URL und der Dateiname hartkodiert. Die Funktion muss jetzt mit url und filename gefüttert werden. Daraus ergeben sich folgende Änderungen:
Nach dem Ausführen liegen nun unter „/screenshots“ vier PNG-Dateien.
Durch den .then Handler wird nach einlösen des Promise screenshot kurz Rückmeldung gegeben. Hiermit zeigt sich auch schön die asynchrone Arbeitsweise von Puppeteer.
In meinem nächsten Artikel werde ich das Skript um einen Vorher-Nachher-Vergleich mit Resemble.js erweitern, sowie das ganze mittels Docker so abpacken, dass man es einfach auf einem Linux-Server ausführen kann.