Beschleunigen Sie die Tests, sagten sie.
Und jetzt ist fast ein halbes Jahr vergangen, seit wir unsere alten, ungeschnittenen, langen und instabilen Funktionstests umgeschrieben und auf schnelle, komponentenunabhängige Tests umgestellt haben. Deshalb ist es Zeit zu teilen :)
Für diejenigen, die es nicht wissen, sind
Komponententests Tests , die vollständig von der globalen Umgebung isoliert sind und es Ihnen ermöglichen, bestimmte Fälle zu überprüfen, die ein
Komponententest nicht abdecken konnte.
Vor sechs Monaten dauerte die Veröffentlichung einer Funktion mehr als eine Stunde, da der Code bereits seit langer Zeit vollständig getestet wurde, die Hauptniederlassung jedoch nicht den grünen Bambusbau erreichen kann. Dann stellte sich die Frage: Wie soll man leben?
In diesem Fall sind Schadenstests in der Tat mehr als gut, aber es ist alles andere als die beste Option, sie loszuwerden und für Tests zu „bewerten“ :) Dann wurde vom Teamleiter ein kleines Mikroteam organisiert:
- Timlida
- Backend-Entwickler
- QS-Ingenieur
- Admin
Nachdem wir schnell zusammengearbeitet hatten, teilten wir unsere Aufgaben auf und eine davon bestand darin, eine Umgebung zum Schreiben von Komponententests einzurichten. Und so begann meine Reise.
Zu Beginn der Entwicklung hatten wir mehr als 140 Funktionstests, die in mehreren Threads unter verschiedenen Umgebungen (Frontend, Mobile, Backend) ausgeführt wurden und ca. 5-7 Minuten dauerten. mussten sie auch oft neu starten, um einen grünen Build zu erreichen. Und diese Tests fielen nicht mehr aufgrund von neu geschriebenem Code aus, sondern aufgrund von Problemen in der Umgebung, dh irgendwo, wo die API nicht reagierte, irgendwo, wo der Testmikroservice fiel usw. Dies stoppte die Arbeit der gesamten Abteilung, da die Baugruppen fast alle 5-10 Minuten begannen: Jemand setzte sich wieder zusammen, jemand drückte einen neuen Code ...
Nach der ersten Hälfte der Woche kamen wir zu dem Schluss, dass wir unsere API- und Drittanbieter-Services „nass machen“ werden, was uns eine vollständig isolierte Testumgebung bieten würde. Aber es stellte sich die Frage: etwas Eigenes zu schreiben oder ... Also endete mit diesem "oder" alles - mit einer kurzen Suche, auf meinem Weg traf ich - eine kleine Betriebszeit in Form des Mock-Servers "http-api-mock".
http-api-mock ist ein leichter und installationsfreier Mock-Server, der in Go mit guter Dokumentation geschrieben wurde.
Nach Hunderten von Startversuchen und allgemeinem Eintauchen in das Thema Mok gelang es mir dennoch, einen Funktionstest neu zu schreiben, der eine neue Anzeige auf der Website erstellte, und nachdem ich alle Höllenkreise bestanden hatte, war ich überzeugt, dass der Titel auf der Seite dem Titel im Hauptteil des Objekts entsprach.
Stellen Sie sich verdient vor! Der umgeschriebene Test erwies sich als dreimal schneller als der vorherige, da wir hier nicht die Erstellung und Moderation überprüft haben, sondern sofort das gewünschte Anzeigenobjekt aus dem Mock zurückgegeben und darauf gewonnen haben. Dieser kleine Sieg wurde zu einem guten Anreiz für die Weiterentwicklung dieses Themas. Nach einer weiteren Woche hatten wir eine neue Codeception-Suite namens „Komponente“, die bereits eine grundlegende Hilfsklasse für die Arbeit mit unserem Mock-Server hatte und zu diesem Zeitpunkt gestartet wurde mich im Sandkasten.
Die Basis-Hilfsklasse kann eine Anzeige in Form einer JSON-Datei im Konfigurationsverzeichnis unseres Mock-Servers erstellen, die gewünschte Anzeige anhand ihrer ID angeben usw. Fast eine API.
Der Rest der Magie wartete weiter auf uns - jetzt blieb nur noch der Montageplan aus Bambus. Damit unsere Tests jetzt unsere CI & CD durchlaufen.
Der Administrator half uns dabei - mit der Einrichtung, alle diese Tests im Docker zu starten, wodurch jeder Build seinen Container mit dem Mock-Server erhöhen und unsere Tests in einer vollständig isolierten Umgebung ausführen konnte, ohne unseren Code für ein Test-Backend bereitzustellen, was auch nicht möglich war Beschleunigen Sie unsere Tests nicht.
Damit all diese Magie funktioniert, mussten wir neue Konfigurationsdateien mit einer neuen API-Adresse und externen Diensten hinzufügen, eine Kopie der MySQL-Datenbank erstellen und mit dem Start unseres Mock-Servers eine neue Aufgabe im Build-Plan erstellen.
Für unseren Code gibt es jetzt eine völlig neue API, die uns unabhängig von Umweltproblemen das bietet, was wir wollen.
Die Zeit verging, die Tests wurden neu geschrieben und aus 140 Funktionstests wurden 103 Komponententests, die in ~ 30 Sekunden parallel abliefen.
Von den Profis
Sehr flink . Aufgrund der Tatsache, dass sie völlig unabhängig von der Testumgebung sind, müssen sie für Daten nicht weit gehen.
Stabil . Tests müssen sich keine Gedanken darüber machen, ob unsere API oder ein anderer Dienst dort gefallen ist, sodass wir immer sicher sind, dass das Ergebnis zu uns kommt.
Einfach zu schreiben . Tatsächlich wurde beim Umschreiben viel entschieden, indem der Code vom alten Funktionstest auf die neue Komponente kopiert und Endpunkte auf dem Mock-Server vorbereitet wurden.
Von den Minuspunkten
Unterstützung . Jetzt geht jeder Entwickler, der Änderungen an der zurückgegebenen Antwort für einen bestimmten Endpunkt in der API vorgenommen hat, auch mit Konfigurationen für den Mock-Server zum Repository und korrigiert dort die Antwort.
Eine Reihe von Dateien . Sie beschlossen, die Daten mit Konfigurationen in Form von Dateien zu speichern, dh jede Antwort für den Endpunkt liegt als Datei und kann irgendwo verloren gehen.
Ergebnisse:
TestsEs war: 140+ Funktionstests = 5-7 Minuten.
Jetzt: 103 Komponententests = ~ 30 Sekunden.
Stabilität aufbauenEs war: Jede dritte Versammlung fiel aufgrund von Problemen.
Es wurde: Stürzt nur, wenn der Entwickler die Logik einer Methode gebrochen hat.
In zukünftigen Plänen müssen wir Akzeptanztests (GUI-Tests) neu schreiben - sie auch im Container ausführen und vom Rest der Umgebung isolieren.