So testen Sie in Autotech: MindMap, statische Code-Analyse und MockServer

    Hallo! Ich möchte Ihnen sagen, wie das Testen im Avtotek- Projekt , dem VIN-Fahrzeuginspektionsdienst, angeordnet ist. Unter dem Schnitt - mit welchen Tools wir die Anforderungen testen, Sprint planen, wie der Testprozess in unserem Projekt abläuft.



    MindMap ist für Putzaufgaben


    Wir in Avtotek verwenden Scram, da dies die erfolgreichste Methode für unsere Aufgaben ist. Jede Woche halten wir Sitzungen , in denen prioritiziruem, die Komplexität bestimmt, zerlegen das Problem der Rückstau und setzen Definition von Ready und Definition der für jede Aufgabe Done (man über sie in lesen kann dieser wunderbaren Artikel ). Dieser Prozess wird als Backlog Grooming bezeichnet.

    Für ein effektives Pflegen müssen alle Abhängigkeiten berücksichtigt werden. Wissen, wie die Implementierung der Aufgabe das Projekt beeinträchtigen kann. Verstehen Sie, welche Funktionen Sie unterstützen müssen und was - geschnitten wird. Bei der Implementierung der Aufgabe kann die API für Partner möglicherweise leiden oder Sie müssen nur daran denken, Metriken zu implementieren, die zum Verständnis der Unternehmenseffizienz verwendet werden können. Mit der Entwicklung eines Projekts werden solche Abhängigkeiten immer mehr und es wird immer schwieriger, sie alle zu berücksichtigen. Das ist schlecht: Es ist wichtig, dass der Supportdienst rechtzeitig über alle Funktionen Bescheid weiß. Und manchmal müssen Innovationen mit der Marketingabteilung abgestimmt werden.

    Als Ergebnis schlug ich eine auf MindMap basierende Lösung vor, bei der fast alle Abhängigkeiten reflektiert wurden, die DoD, DoR und Aufgabenbewertung beeinflussen könnten.



    Der Vorteil dieses Ansatzes ist die visuelle Darstellung aller möglichen Abhängigkeiten in einem hierarchischen Stil sowie zusätzliche Brötchen in Form von Symbolen, Texthervorhebung und farbigen Zweigen. Zugriff auf diese MindMap hat das gesamte Team, wodurch Sie die Karte auf dem neuesten Stand halten können. Ein Rohling einer solchen Karte, die als Bezugspunkt genommen werden kann, poste ich hier - pyn . (Ich werde sofort reservieren, dass dies nur eine Richtlinie ist, und es ist sehr zweifelhaft, diese Karte für Ihre Aufgaben zu verwenden, ohne das Projekt zu überarbeiten.)

    Linty und statische Code-Analyse für Go



    In unserem Projekt wurde relativ viel Golang-Code verwendet, und damit der Code-Stil bestimmte Standards erfüllt, wurde die statische Codeanalyse beschlossen. Über das, was es ist, gibt es einen großartigen Artikel über Habré .
    Wir wollten den Analysator in den CI-Prozess einbauen, so dass mit jedem Build des Projekts der Analysator gestartet wurde und je nach Testergebnis der Build mit Fehlern fortgesetzt oder abgebrochen wurde. Im Allgemeinen wäre die Verwendung von gometalinter als separater Schritt (Build-Schritt) in Teamcity eine gute Lösung, aber das Anzeigen von Fehlern in den Build-Protokollen ist nicht sehr bequem.
    Wir suchten weiter und fanden den Linty Bot, der im Rahmen des Hackathons in Avito von Artemy Flaker Ryabinkov entwickelt wurde.



    Dies ist der Bot, der den Projektcode in unserem Versionskontrollsystem verfolgt und mit jeder Pull-Anforderung einen Diff-Code-Analysator startet. Wenn während der Analyse Fehler aufgetreten sind, sendet der Bot einen Kommentar an dieses PR in der gewünschten Codezeile. Seine Vorteile sind die Verbindungsgeschwindigkeit zum Projekt, die Arbeitsgeschwindigkeit, Kommentare zum Abrufen von Requests und die Verwendung des recht beliebten Gometalinter-Linters, der standardmäßig bereits alle erforderlichen Überprüfungen enthält.

    MockServer und wie Sie Services bekommen, um das zu geben, was Sie brauchen


    Bild

    Der nächste Abschnitt befasst sich mit der Stabilität der Tests. Autotech ist in hohem Maße von Datenquellen abhängig (sie stammen von Händlern, Regierungsbehörden, Tankstellen, Versicherungsgesellschaften und anderen Partnern), aber ihre Funktionsfähigkeit kann nicht die Grundlage für die Weigerung sein, Tests durchzuführen.

    Wir müssen die Zusammenstellung der Berichte sowohl mit den Arbeitsquellen als auch mit ihrer Funktionsunfähigkeit überprüfen. Bis vor kurzem haben wir echte Datenquellen in der Entwicklungsumgebung verwendet und waren daher abhängig von ihrem Zustand. Es stellte sich heraus, dass wir diese Quellen in UI-Tests indirekt überprüft haben. Als Ergebnis hatten wir instabile Tests, die zusammen mit den Quellen abfielen, und warteten auf die Erhebung von Datenquellen, die nicht zum Durchlaufen von Autotests beitrugen.

    Ich hatte die Idee, meinen eigenen Moke zu schreiben und so die Quellen von Autotech zu ersetzen. Am Ende wurde jedoch eine einfachere Lösung gefunden - ein vorgefertigter MockServer , eine Open-Source-Java-Entwicklung.

    Das Prinzip seiner Arbeit:

    • Erwartung schaffen
    • eingehende Anfragen abgleichen
    • Wenn eine Übereinstimmung gefunden wird, senden Sie eine Antwort.

    Ein Beispiel zum Erstellen einer Wartezeit mit einem Java-Client:

    new MockServerClient("localhost", 1080)
        .when(
            request()
                .withMethod("POST")
                .withPath("/login")
                .withBody("{username: 'foo', password: 'bar'}")
        )
        .respond(
            response()
                .withStatusCode(302)
                .withCookie(
                    "sessionId", "2By8LOhBmaW5nZXJwcmludCIlMDAzMW"
                )
                .withHeader(
                    "Location", "https://www.mock-server.com"
                )
        );
    

    Anscheinend beschreiben wir aus einem Beispiel die Anfrage, die wir senden, und die Antwort, die wir erhalten möchten. MockServer empfängt die Anfrage und versucht, sie mit den erstellten zu vergleichen. Wenn Übereinstimmung vorliegt, wird eine Antwort zurückgegeben. Wenn die Anforderung nicht übereinstimmt, wird 404

    angezeigt. Für MockServer gibt es Clients für Java und JavaScript, hervorragende Dokumentations- und Verwendungsbeispiele. Es ist möglich, Anforderungen über RegExp, eine detaillierte Protokollierung auf dem Server und eine ganze Reihe verschiedener Chips abzugleichen. Für unsere Bedürfnisse war dies der perfekte Kandidat. Der Startvorgang wird auf der Website ausführlich beschrieben, sodass das Nacherzählen hier nicht angezeigt wird. Der einzige Punkt ist, dass die neueste Version ziemlich aus dem Speicher läuft und wir die Version 5.2.3 verwenden. Seien Sie aufmerksam. Ein weiterer Nachteil besteht darin, dass der Mockserver keine SOAP-Unterstützung bietet.

    Momentan arbeitet MockServer seit etwa drei Monaten mit uns zusammen. Die Stabilität von Tests, ihre Geschwindigkeit und die Fähigkeit, Daten in der Entwicklungsumgebung zu empfangen, sind daher gestiegen. Und dementsprechend mehr Testmöglichkeiten.

    Epilog


    Diese Technologien sind die wichtigsten Dinge, über die ich in diesem Artikel sprechen möchte. Ansonsten verwenden wir die üblichen Tools zum Testen: API-Tests mit einer Reihe von Kotlin + JUnit + RestAssured, Postman für einen einfachen Zugriff auf die API. In diesem Übersichtsartikel habe ich nicht über unsere Vorgehensweise bei UI-Tests gesprochen. Wir verwenden MBT und Graphwalker . Wir planen mit Kollegen, einen Post darüber vorzubereiten.

    Wenn Sie Fragen haben, fragen Sie in den Kommentaren, ich werde versuchen zu antworten. Ich hoffe, dieser Artikel wird für Entwicklungsteams nützlich sein. (Übrigens, während sie sich auf die Veröffentlichung vorbereitete, hatten wir eine freie Stelle für QS-Entwickler im Team , zeigen Sie, wer daran interessiert ist.)

    Jetzt auch beliebt: