Hallo! Ich möchte Ihnen sagen, wie die Tests im
Autotech- Projekt, einem Autoinspektionsdienst von VIN,
funktionieren . Unter dem Strich - darüber, mit welchen Tools wir Anforderungen testen, Sprintplanung, wie der Testprozess in unserem Projekt funktioniert.
MindMaps für die Pflege von Aufgaben
Wir verwenden Scrum im Auto Center, da dies die erfolgreichste Methode für unsere Aufgaben ist. Wöchentlich halten wir Besprechungen ab, bei denen wir Prioritäten setzen, die Komplexität bestimmen, Rückstandsaufgaben zerlegen und für jede Aufgabe die Definition von Bereit und die Definition von Fertig festlegen (Sie können darüber in
diesem wunderbaren Artikel lesen). Dieser Vorgang wird als Backlog-Grooming bezeichnet.
Für eine effektive Pflege müssen alle Abhängigkeiten berücksichtigt werden. Wissen, wie sich die Implementierung der Aufgabe negativ auf das Projekt auswirken kann. Verstehen Sie, welche Funktionen Sie unterstützen und welche Sie schneiden müssen. Möglicherweise leidet bei der Implementierung der Aufgabe die API für Partner, oder Sie müssen nur daran denken, Metriken zu implementieren, anhand derer Sie die Geschäftseffizienz verstehen können. Mit der Entwicklung eines Projekts gibt es immer mehr solche Abhängigkeiten, und ihre Berücksichtigung wird immer schwieriger. Das ist schlecht: Es ist wichtig, dass sich das Support-Team rechtzeitig über alle Funktionen informiert. Und manchmal müssen Innovationen mit der Marketingabteilung abgestimmt werden.
Als Ergebnis schlug ich eine auf MindMap basierende Lösung vor, die fast alle Abhängigkeiten widerspiegelte, die sich auf DoD, DoR und Aufgabenbewertung auswirken könnten.
Der Vorteil dieses Ansatzes ist eine visuelle Darstellung aller möglichen Abhängigkeiten in einem hierarchischen Stil sowie zusätzliche Brötchen in Form von Symbolen, Textauswahl und mehrfarbigen Zweigen. Das gesamte Team hat Zugriff auf diese MindMap, mit der Sie die Karte auf dem neuesten Stand halten können. Ich breitete hier den Rohling einer solchen Karte aus, die als Wahrzeichen dienen kann -
Melone . (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 abzuschließen.)
Linty und statische Code-Analyse für Go
In unserem Projekt wurde eine relativ große Anzahl von Golang-Code verwendet, und damit der Codestil bestimmte Standards erfüllt, wurde beschlossen, eine statische Code-Analyse anzuwenden. Über das, was es ist, gibt es einen ausgezeichneten
Artikel über Habré.
Wir wollten den Analysator in den CI-Prozess integrieren, damit der Analysator bei jedem Build des Projekts gestartet wird. Abhängig von den Ergebnissen der Überprüfung wurde der Build fortgesetzt oder stürzte mit Fehlern ab. Im Allgemeinen wäre die Verwendung von gometalinter als separaten Build-Schritt in Teamcity eine gute Lösung, aber das Anzeigen von Fehlern in Build-Protokollen ist nicht sehr praktisch.
Wir suchten und fanden weiter den Linty Bot, der im Rahmen des Avito-
Hackathons von Artemy
Flaker Ryabinkov entwickelt wurde.
Dies ist ein Bot, der den Projektcode in unserem Versionskontrollsystem überwacht und bei jeder Pull-Anforderung einen Diff-Code-Analysator startet. Wenn während der Analyse ein Fehler auftritt, sendet der Bot einen Kommentar an diesen PR an die gewünschte Codezeile. Seine Vorteile sind die Geschwindigkeit der Verbindung zum Projekt, die Arbeitsgeschwindigkeit, Kommentare zu Pull-Anfragen und die Verwendung des beliebten Gometalinter-Liners, der standardmäßig bereits alle erforderlichen Überprüfungen enthält.
MockServer und wie man Dienste dazu bringt, das zu geben, was sie brauchen
Der nächste Abschnitt befasst sich mit der Teststabilität. Das Autohaus ist extrem abhängig von Datenquellen (sie stammen von Händlern, staatlichen Stellen, Tankstellen, Versicherungsunternehmen und anderen Partnern), aber ihre Inoperabilität kann nicht die Grundlage für die Weigerung sein, Tests durchzuführen.
Wir müssen die Zusammenstellung von Berichten sowohl an Arbeitsquellen als auch auf deren Inoperabilität überprüfen. Bis vor kurzem haben wir reale Datenquellen in der Entwicklungsumgebung verwendet und waren dementsprechend von ihrem Status abhängig. Es stellte sich heraus, dass wir diese Quellen indirekt in UI-Tests überprüft haben. Infolgedessen hatten sie instabile Tests, die zusammen mit den Quellen abfielen und auf eine Übersicht der Datenquellen warteten, was nicht zur Geschwindigkeit des Bestehens automatischer Tests beitrug.
Ich hatte die Idee, mein eigenes Modell zu schreiben und damit die Quellen von Autotech zu ersetzen.
Am Ende wurde jedoch eine einfachere Lösung gefunden - der fertige
MockServer , Open-Source-Entwicklung in Java.
Das Prinzip seiner Arbeit:
- Erwartungen schaffen
- eingehende Anfragen abgleichen,
- Wenn eine Übereinstimmung gefunden wird, senden Sie eine Antwort.
Ein Beispiel für das 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" ) );
Wie Sie dem Beispiel entnehmen können, beschreiben wir die Anfrage, die wir senden, und die Antwort, die wir erhalten möchten. MockServer empfängt die Anforderung, versucht, sie mit den erstellten zu vergleichen, und gibt bei Übereinstimmungen eine Antwort zurück. Wenn die Anfrage nicht fehlschlägt, erhalten wir 404.
Für MockServer gibt es Clients für Java und JavaScript, eine hervorragende Dokumentation und Anwendungsbeispiele. Es besteht die Möglichkeit, Anfragen auf RegExp abzugleichen, eine detaillierte Protokollierung auf dem Server und eine ganze Reihe von Chips durchzuführen. Für unsere Bedürfnisse war es ein idealer Kandidat. Der Startvorgang wird auf der Website ausführlich beschrieben, sodass das Nacherzählen hier keinen Sinn ergibt. Im einzigen Moment war die neueste Version ziemlich durchgesickert, daher verwenden wir Version 5.2.3. Seien Sie aufmerksam. Ein weiteres Minus ist, dass Mockserver keine sofortige SOAP-Unterstützung bietet.
Im Moment arbeitet MockServer seit ungefähr drei Monaten mit uns zusammen. Infolgedessen haben die Stabilität von Tests, die Geschwindigkeit ihrer Ausführung und die Fähigkeit, Daten in einer Entwicklungsumgebung zu empfangen, zugenommen. Dementsprechend gibt es mehr Möglichkeiten zum Testen.
Nachwort
Diese Technologien sind die wichtigsten Dinge, über die ich in diesem Artikel sprechen möchte. Andernfalls verwenden wir die üblichen Testtools: API-Tests mit dem Kotlin + JUnit + RestAssured, Postman-Bundle, um den Zugriff auf die API zu vereinfachen. In diesem Übersichtsartikel habe ich nicht über unseren Ansatz für UI-Tests gesprochen. Wir verwenden MBT und
Graphwalker . Wir planen, einen Beitrag mit Kollegen darüber vorzubereiten.
Wenn Sie Fragen haben, fragen Sie in den Kommentaren, ich werde versuchen zu beantworten. Ich hoffe, dieser Artikel ist nützlich für Entwicklungsteams. (Übrigens, während sie sich auf die Veröffentlichung vorbereitete, erschien ein
QA-Entwicklerjob in unserem Team, zeigen Sie denen, die daran interessiert sein könnten).