Autotests für Projekte sind erforderlich. Wie sie sagen, kann die Automatisierung von Geschmack und Farbe jedoch unterschiedlich sein. Wir kamen zu einem Projekt, in dem es bereits Autotests gab, und konnten die Abdeckung verbessern und den Testdurchlauf beschleunigen, ohne dass es zu einer grundlegenden Revolution kam. Unter der Katze darüber, wie wir es gemacht haben.
Ein paar Worte zum Projekt
Obwohl wir die Details des Projekts aufgrund der NDA nicht offen legen können, lautete die Aufgabe im Allgemeinen wie folgt. Wir haben uns an der Entwicklung des Fintech-API-Service beteiligt, der mit der Datenbank interagiert und die erforderlichen Finanzobjekte (Preise, Tarife usw.) zurückgibt. Unsere Aufgabe war es, mobile Clients für diesen Service zu testen - sowohl für Webanwendungen als auch für native mobile Anwendungen.
Die Testautomatisierung für dieses Projekt entwickelte sich schrittweise zusammen mit der Komplexität des Dienstes. Dies ist wahrscheinlich, wie lange End-to-End-Tests auf einmal aufgetreten sind, die wir im Projekt gefunden haben. Die meisten von ihnen funktionierten zu diesem Zeitpunkt noch nicht, da sich der Service geändert hatte und es niemanden gab, der die Tests unterstützte - der einzige Automatisierungstechniker verließ das Projekt lange bevor wir ankamen.
Sogar die Tests, die der Funktionalität zu entsprechen scheinen, fielen manchmal aufgrund von Versionsverwechslungen oder mangelnder Verfügbarkeit externer Ressourcen. Zum Testen wurde eine separate Infrastruktur verwendet - Teststände, auf denen die erforderlichen Versionen für Experimente bereitgestellt wurden. Verschiedene Arbeitsgruppen hatten Zugang dazu und agierten nicht immer gemeinsam. Infolge der Aktionen einer Gruppe könnten einige wichtige APIs, die von unserem Service verwendet werden, ausfallen, weshalb sogar ein funktionierender Test nicht mehr bestand. Das heißt Der Test zeigte nicht mehr die Servicefreundlichkeit des Service selbst, sondern bezog sich auf die gesamte Testinfrastruktur.
Wie wir ins Chaos kamen
Es scheint, dass es in dieser Situation notwendig ist, alle alten Errungenschaften aufzugeben und die Tests neu aufzubauen. Aber wir haben „menschlicher“ gehandelt. Die Teststruktur selbst blieb erhalten und konzentrierte sich auf die Lösung spezifischer Probleme - langsamer Testdurchlauf, deren Instabilität und unzureichende Abdeckung von Testfällen. Für jeden von ihnen gab es eine Lösung.
Refactoring
Zunächst haben wir den Code alter Tests teilweise überarbeitet, wobei wir uns auf modernere Entwurfsmuster gestützt haben.
Ein Teil des alten Codes musste entfernt werden - die Wartung war zu schwierig. In einem anderen Teil haben wir alle Schwächen aufgefangen - wir haben den Standardschlaf durch normale Wartezeiten ersetzt, Vorbereitungen für alle Tests im globalen Setup getroffen, über Anmerkungen von Testläufern usw. Viele kleine Schritte reduzierten den durchschnittlichen Testdurchlauf von Ende zu Ende von 3-4 auf 1-2 Minuten.
Atomarer Ansatz
Um die Erstellung neuer Tests zu beschleunigen und die Unterstützung alter zu vereinfachen, haben wir uns von umständlichen End-to-End-Fällen verabschiedet.
Persönlich habe ich nichts grundsätzlich gegen End-to-End-Tests, aber wenn Sie einen bestimmten Bildschirm (oder sogar einen Teil der Informationen darauf) überprüfen müssen, ist es zu teuer, alle Schritte beginnend mit der Benutzerautorisierung durchzugehen. Stellen Sie sich vor, wir testen einen Online-Shop und müssen nur den Scheck prüfen, der nach dem Kauf eines bestimmten Produkts an den Käufer gesendet wird. Anstatt nur einen Bildschirm aus dem System abzurufen, würden wir uns per Login und Passwort anmelden, das Produkt auswählen, den Kauf bestätigen usw. - würde viele Schritte ausführen, die sich nicht auf eine bestimmte Testaufgabe beziehen. Aber jeder Schritt braucht Zeit. Trotz aller durchgeführten Optimierungen dauerte der Start des End-to-End-Tests bis zu 2 Minuten, während die Überprüfung eines bestimmten Bildschirms nur 10 Sekunden dauerte. Wo es möglich war, gingen wir daher zu solchen „atomaren“ Überprüfungen über und bezogen uns nur auf den Bildschirm, der uns als Teil des Testfalls interessiert.
Nebenbei haben wir nur zum Vergleich des Bildschirms einen Schnappschuss-Test implementiert, mit dem Sie den Löwenanteil der Benutzeroberfläche überprüfen können. Mit Tests und Anwendungscode in einem Repository können wir die Methoden dieser Anwendung in Tests verwenden, d. H. Heben Sie alle Bildschirme an, die in diesem Prozess benötigt werden. So können wir Fehler beim Vergleich von Test-Screenshots mit Referenz-Screenshots finden.
Wir haben jetzt ungefähr 300 Schnappschusstests, und ihre Anzahl nimmt allmählich zu, da dieser Ansatz die Zeit, die zum Überprüfen der fertigen Version vor dem Senden an die Produktion benötigt wird, erheblich verkürzen kann. Diese Tests werden beim Öffnen der Pull-Anforderung automatisch gestartet und in 40 Minuten ausgeführt. Entwickler erhalten daher schnelles Feedback zu Problemen in der aktuellen Branche.
Natürlich sind eine Reihe von End-to-End-Tests erhalten geblieben. Sie können nicht darauf verzichten, wenn Sie umfangreiche Geschäftsszenarien überprüfen müssen. Es ist jedoch sinnvoll, sie auszuführen, wenn alle Details bereits überprüft wurden.
Verspotten
Um den Einfluss eines instabilen Prüfstands auf das Ergebnis des Starts unserer Tests auszuschließen, haben wir einen Mock-Server gestartet. Über welche Entscheidungen wir uns dann Gedanken gemacht haben und warum wir uns für Okhttpmockwebserver entschieden haben, habe
ich bereits bei Habré geschrieben .
Infolgedessen verringerte sich der Anteil der episodisch abfallenden Tests aufgrund externer Testursachen erheblich.
Kotlin DSL
Parallel dazu haben wir die Tests lesbarer gemacht.
Diejenigen, die an UI-Tests beteiligt sind, wissen, wie schwierig es ist, die Wahrheit unter einer Reihe von Lokalisierern in der langen "Fußdecke" des Tests zu finden (insbesondere in der Phase, als es noch End-to-End-Tests waren). Es ist einfach, in ihnen zu navigieren, wenn Sie zwei Jahre lang an einem Projekt gearbeitet haben, und selbst mitten in der Nacht können Sie sich merken, was was ist. Aber wenn Sie gerade gekommen sind, ist es eine separate große Aufgabe, sich auf das einzulassen, was gerade passiert. Damit sich neue Leute nicht jedes Mal darum kümmern müssen, haben wir uns für den Wechsel zu Kotlin DSL entschieden. Es ist sehr einfach zu implementieren und hat eine einfache und verständliche Struktur. Wenn die Tests früher aus einer Reihe von identischen Aufrufen auf niedriger Ebene bestanden - Klicken, Texteingabe, Scrollen -, hat sich dies nun zu etwas „Geschäftsmäßigerem“ entwickelt - so etwas wie einem BDD-Ansatz. Alles ist sichtbar und verständlich.
Das hat uns meiner Meinung nach eine gewisse Reserve für die Zukunft gemacht. Dieses Projekt war bereits einmal dem Abgang eines einzelnen Automatisierungsingenieurs ausgesetzt. Für die Tests endete dies nicht im besten Sinne - sie hörten einfach auf, sie zu unterstützen, weil sich herausstellte, dass die Eintrittsschwelle zu hoch war. Das Verständnis eines solchen trockenen Codes erforderte viel Zeit und eine gewisse Qualifikation. Wir haben die Tests so überarbeitet, dass es jederzeit möglich ist, Personen schnell aus anderen Projekten oder von manuellen Tests in die Automatisierung zu überführen. Fast jeder kann die einfachsten Tests auf Kotlin DSL schreiben. So kann die Automatisierung die einfache Implementierung verlassen und schnell neue einfache Tests schreiben, um die Mitarbeiter des Funktionsteams zusammenzubringen. Sie verfügen über ausreichende Kenntnisse der Geschäftslogik, und das Projekt wird von der Tatsache profitieren, dass sie stärker in den Prozess des Schreibens von Autotests involviert sein werden. Mit Kotlin DSL können Sie Testfälle genau so beschreiben, wie sie alle Überprüfungen sehen möchten, so dass die Implementierung von Methoden auf niedriger Ebene nicht in ihren Arbeitsbereich fällt.
All dies ermöglichte es im Allgemeinen, die Abdeckung von Autotests schneller zu erhöhen. Wenn die Implementierung der neuen Testsuite früher 16 bis 20 Stunden gedauert hat, dauert die Implementierung mit dem neuen Ansatz je nach Komplexität der Tests 4 bis 12 Stunden (und die Arbeitskosten für den Support wurden von 16 bis 24 auf 8 bis 12 Stunden gesenkt Woche).
Artikel Autor: Ruslan Abdulin.
PS Wir veröffentlichen unsere Artikel auf mehreren Seiten des Runet. Abonnieren Sie unsere Seiten auf
VK ,
FB ,
Instagram oder dem
Telegrammkanal , um mehr über unsere Veröffentlichungen und andere Neuigkeiten von Maxilect zu erfahren.
PPS Helfen Sie uns, unsere Blog-Artikel interessanter zu gestalten:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .