Jeder, der Software entwickelt, kennt das Problem: Die Arbeit läuft, es geht voran, aber für die letzten 20% der Arbeit braucht man dann 80% der Zeit. Irgendein Randfall oder eine Lücke in den Features einer Library, eine merkwürdige Kundenanforderung, komische modellierte Daten. Tada, der frühe Feierabend oder der pünktliche Sprint-Abschluss ist dahin. Ständig verbraten wir Arbeits- und Lebenszeit auf den Abwegen vom Happy-Path.

Meine folgende Story hat damit nichts zu tun… Sie handelt davon, wie man auch schon auf dem Happy-Path so oft stolpern kann, dass man am liebsten lachend in eine Kreissäge rennen möchte. Sie handelt auch davon, wie man manchmal einen regelrechten Hass auf zentral gesteuerte Konzern-IT bekommen kann, und wie wenig die hippe Welt der Web-Entwicklung auf solche Umstände Rücksicht zu nehmen scheint. Ich sollte an dieser Stelle dazu sagen, dass ich als Freelancer oft in Kundenprojekten von Konzernen oder Mittelständlern unterwegs bin. Dort ist die IT in der Regel zentral gesteuert und sehr restriktiv. Oft haben nicht einmal die Leute in den Entwicklungsabteilungen auf ihren Rechnern Admin-Rechte.

Aber kommen wir zum Kern: So ergab es sich, dass ich bei einem meiner Kunden eine neue Angular Anwendung aufsetzen sollte. Wie es sich für einen guten Entwickler gehört, wollte ich auch für die neuen Features direkt einen kleinen Satz an End-to-End Tests bauen. Damit nahm das Unheil seinen Lauf.

Teil 1:
Der erste Versuch, und schon legt sich Protractor aka Webdriver aka Selenium etc. auf die Fresse.

Grund: Es war keine Java Runtime installiert. Bis diese installiert war, ging eine Woche ins Land (keine Admin-Rechte, Genehmigungsverfahren, Remote-Installation per Helpdesk). Eine Woche war sogar verhältnismäßig schnell…

Teil 2:
Freudig versucht Protractor laufen zu lassen, und schon legt es sich wieder auf die Fresse. Grund: Das automatische Updaten der webdriver-manager Abhängigkeiten läuft auf einen Timeout, konkret: Error: connect ETIMEDOUT …
Schuld diesmal: Der Proxy-Server. Das kannte ich schon, da ich Proxy-Server schon aus vielen Projekten gewöhnt war. Die Lösung für den webdriver-manager:
set HTTP_PROXY=http://somecompany-proxy:1234
set HTTPS_PROXY=http://somecompany-proxy:1234

Teil 3:
Und weiter geht es, ich habe es doch jetzt geschafft, oder? Weit gefehlt! Wieder legt sich das Teil auf die Fresse, denn: Die Automatik vom webdriver-manager zieht natürlich die neuste Version des ChromeDrivers, also des Teils, über den der Chrome Browser ferngesteuert wird. Wenn man nicht den neusten Chrome installiert hat resultiert das aber leider in folgender Meldung:
E/launcher – session not created exception: Chrome version must be >= 64.0.3282.0
Na super, was macht man als Entwickler, wenn man schon tagelang kämpfen musste, um überhaupt einen Chrome installiert zu bekommen, und ihn nicht einfach updaten kann? Für die friedlichen unter uns:
webdriver-manager update --chrome --versions.chrome=2.36

Teil 4:
Womit wir direkt zum nächsten Punkt kommen. Das hilft natürlich nicht, denn der Automatismus, der über ng e2e aufgerufen wird, nutzt irgendeine fest in einer .config Datei verdrahtete Version von ChromeDriver. Diese .config Datei wird mit npm ausgeliefert und ist daher kein guter Ort um sie zu ändern, da andere Entwickler sonst von der eigenen Vorarbeit nicht profitieren. Auch etwas was ich leidvoll erfahren musste und erst nach einiger Recherche beheben konnte.
Die Lösung hier ist ein Verweis auf die ChromeDriver Version in der protractor.conf.js:
chromeDriver: 'C:/ChromeDriver/chromedriver_xx.exe', ...

Warum der absolute Pfad? Bei global installiertem Protractor würde die Version sonst in den AppData Ordner des Benutzers installiert (ich befinde mich auf einem Windows System), den man mit Umgebungsvariablen oder ähnlichem Kram auflösen müsste. Es muss also auch das Updaten des webdriver-managers in diesen Ordner gesteuert werden:
webdriver-manager update --chrome --versions.chrome=2.36 --out_dir C:\ChromeDriver

Teil 5:
ng e2e
Und es läuft!!! Scheiß‘ die Wand an…

Fazit
Ich hoffe dieser Artikel hilft möglicherweise einigen, die auf ähnliche Probleme wie ich gestoßen sind. Dann hätte ich zumindest etwas positives damit erreicht, mal abgesehen von Frustverarbeitung 🙂 Aber so hatte ich wenigstens ein wenig Spaß beim Dampf ablassen.

Und die Moral von der Geschichte? Ich hasse Konzern-IT! Sie hindert ständig Menschen daran, ihre Arbeit richtig zu machen. Jaja, in manchen Fällen mögen restriktive Vorgaben durch die zentrale IT durchaus sinnvoll sein. Ich habe sogar aus eigener persönlicher Erfahrung sehr viel Verständnis dafür, da ich viele Monate selbst in der Administration und im Helpdesk diverser Unternehmen unterwegs war. Aber für Rechner von Softwareentwicklern ist das in etwa so, als würde man einem Künstler sagen, er solle doch ein schönes kreatives buntes Bild malen, aber bitte nur mit den freigegebenen Konzern-Bleistiften. Ralf Westfal hat dazu in der dotnetpro einen wundervollen Artikel geschrieben, der es sehr gut zusammenfasst: https://www.dotnetpro.de/diverses/lesenswert/strategien-talentkrieg-1459619.html. Leider ist der Artikel nicht öffentlich verfügbar. Für Links zu anderen Artikeln dieser Art bin ich immer dankbar! Diese Produktivitäts- und Motivationsvernichtung in deutschen Unternehmen kann man nicht oft genug anprangern 🙂