In diesem Beitrag möchte ich einen Überblick über 15 Berichte der Heisenbug-Konferenz geben, Ihnen mitteilen, was an den Ständen der Unternehmen interessant war, und Videomaterial aus dem Bericht von Artyom Eroshenko über die Erstellung von Aktions-Plugins für IntelliJ IDEA, mit denen Sie den Code des Testprojekts schnell ändern können.
Informationen zu HeisenBug
Heisenbug - Technische Konferenz für
Prüfspezialisten . Es ist hauptsächlich für Tester, Softwareentwickler im Test und Spezialisten für automatisierte Tests und Lasttests von Interesse. Die Organisatoren sind das
JUG.RU- Team, hinter dem Konferenzen wie Joker, HolyJS, SmartData, DevOops, DotNext und Mobius stehen.
Veranstaltungort
Die fünfte Konferenz fand im Slavyanskaya Radisson Hotel in der U-Bahn-Station Kievskaya in Moskau statt. Bei der Annäherung an das Hotel war ein elektronisches Banner mit dem Konferenzlogo sichtbar. Am Eingang zur Hotellobby wurde der Teilnehmer von Schildern zu den Check-in-Schaltern und zum Kleiderschrank begleitet. Es ist unmöglich, sich zu verlaufen. Die Registrierung der Teilnehmer und Redner erfolgte im Erdgeschoss, in der Hauptlobby der Konferenz befanden sich Partnerstände, Konferenzräume, Säle mit Kaffeepause und Mittagessen. Das Niveau der Sicherheitskräfte gefiel, so dass "blinde Kaninchen" nicht zu bekommen waren. Insgesamt nahmen mehr als 500 Teilnehmer an der Veranstaltung teil, von denen sich die meisten zwei Wochen vor dem Start anmeldeten.
Das Programm
Das Programm finden Sie
hier . Ich möchte darauf hinweisen, dass
JUG.RU stets bemüht ist, das Programm ohne zusätzliches Wasser und mit bekannten ausländischen Experten praktisch zu gestalten. Die Berichte sind in Symbole unterteilt:
Wenn Sie zum ersten Mal vorhaben, Redner bei Heisenbag zu werden, lesen Sie
das Memo des
Redners - es enthält viele nützliche Informationen.
Kommunikation und Freiwilligenarbeit
Damit die Teilnehmer auf der Konferenz nichts Wichtiges verpassten, wurden ein Telegrammkanal und ein Telegrammchat organisiert. Übrigens suchten sie in letzterem nach Freiwilligen, um Videos anzusehen, für die sie ein kostenloses Konferenzticket gaben.
Wenn Sie sich entscheiden, Freiwilliger zu werden, teilen Sie dies den Organisatoren so früh wie möglich mit. Die Vorbereitung auf die Veranstaltung erfolgt lange vor der Konferenz. Je nach Verfügbarkeit werden Sie dem Team zugewiesen.
Unternehmen steht
Diesmal waren mehr als ein Dutzend Stände großer IT-Unternehmen wie die Deutsche Bank, die Alfa-Bank, Raiffeisen, Badoo, Luxoft, SKB Kontur, Gett usw. an der Konferenz beteiligt. Jedes Unternehmen ging die Organisation der Interaktionen mit den Teilnehmern auf seine Weise an. , dazwischen mussten sich die Vorstellungen nicht langweilen. Es war möglich, Probleme für ein kleines unvergessliches Souvenir zu lösen, Video- und Brettspiele zu spielen und an der Lotterie teilzunehmen.
Raiffeisen bot an, eine Online-Suche mit einer Lösung für alle Arten von Rätseln zu durchlaufen. Auch Kenner zeitloser Klassiker konnten Mortal Kombat 3 auf Sega spielen. Die Kollegen der Alfa-Bank erstellten einen Telegramm-Bot mit Aufgaben sowie eine große Anzahl von Lego Mindstorms, die in der Lotterie gespielt wurden. Ich möchte den Stand der Deutschen Bank loben, an dem Entwickler in der Live-Kommunikation Aufgaben verteilten und an der Diskussion teilnahmen, im Gegensatz zu allen anderen Ständen, an denen sie nur die Antworten überprüften.
Viele Unternehmen jagen unauffällig Spezialisten und verteilen Broschüren, in denen die offenen Stellen beschrieben werden (nicht alle, um sich für wohltätige Zwecke zu engagieren).
Berichtsübersicht
1. Wir haben DevOps. Lassen Sie uns alle Tester feuern - Baruch Sadogursky.
Die Konferenz wurde von Baruch Sadogursky, Entwickleranwalt von JFrog, eröffnet, einem bekannten Redner bei Konferenzen zu Java und Devops. In dem Bericht ging Baruch auf die Probleme der Softwarequalität angesichts häufiger Releases ein, die durch ständig wachsende Geschäftsanforderungen, die Komplexität von Codetests aufgrund schlechter Architektur und die Modernisierung der Rolle des Testers in modernen agilen Teams verursacht werden. Der Bericht war von Anfang bis Ende interessant zu hören, viel Humor, interessante Fakten und Vergleiche.
Nun, die Hauptgedanken des Berichts können auf einer Folie zusammengefasst werden. Dies zeigt, dass Testautomatisierung und DevOps-Praktiken die Zeitkosten von Routineprozessen senken und es Ihnen ermöglichen, mehr Zeit für die Implementierung neuer Aufgaben aufzuwenden.
2. Müssen Sie ein Projekt umgestalten? Es gibt IDEE! - Artem Eroshenko.
Artyom sprach in seinem Bericht über das Erstellen von
Aktions- Plug-Ins für IntelliJ IDEA, mit denen Sie den Code des Testprojekts schnell ändern können.
Er gab eine Erklärung der Hauptklassen (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager), die den Eingabepunkt von Plugin-Aktionen sind.
Überlegt, wie die folgenden Aufgaben gelöst werden können:
a) Was ist im Projekt automatisiert und was nicht? Automatische Synchronisierung mit Jira.
Gemäß dem Anmerkungstext ging @DisplayName zu Jira, erhielt die erforderlichen Tickets und stellte alle erforderlichen Verbindungen mit @TmsLink her.
b) Fügen Sie @Tags automatisch aus dem Jira-Kontext hinzu.
Das
bevorzugte Regressionsticket enthält bestimmte Labels. Wir gehen zum Test, es gibt @ TmsLink-Annotationen, wir verwenden das Plugin und wir haben neue @ Tags-Annotationen, und dann können wir mit Hilfe von Junit Tests für diese Tags ausführen.
c) Was wird in den Tests überprüft?
Es gibt einen Autotest, es gibt Schritte, wir exportieren und wir haben Schritte in den Tests. Auch im Video gibt es ein Beispiel für zwei Tests.
Artyom zeigte auch, wie man schnell von Allure 1 zu Allure 2 wechselt.
Ein sehr praktischer Bericht für diejenigen, die darüber nachdenken, den Prozess des Schreibens von Code zu optimieren. Den Quellcode der Plugins finden Sie
hier .
3. Java- und Reaktorprojekt? - Aber was ist mit den Tests? - Kirill Merkushev.
Cyril teilte seine Erfahrungen bei der Entwicklung des internationalen medizinischen Startups Vivy. Er erzählte, wie die Probleme der Skalierbarkeit eines monolithischen Systems mithilfe von Microservices und der Reactor Library gelöst wurden. Viel Aufmerksamkeit wurde dieser Bibliothek, ihren Grundprinzipien, Ansätzen zum Testen reaktiver Systeme, Killerfunktionen (wie Prüfpunkten und Protokollen in der Anforderungskette, Hooks und wiederholten Anforderungen (erneuter Versuch) gewidmet.
Persönlich habe ich mich nicht mit dem Testen reaktiver Systeme befasst, daher war es für mich neu und interessant.
4. Als wir das Sealant-Framework für die Suche nach Speicherlecks in JS geschrieben haben , hat Sergey Dokuchaev.
In diesem Vortrag geht es um Speicherverluste (Objekte, auf die über den Code zugegriffen werden kann, die aber nicht mehr benötigt werden) in einseitigen Webanwendungen. Sergey hat die Aufgabe so eingestellt, dass alle kritischen Speicherlecks in der freigegebenen Version des Produkts automatisch gefunden werden. Er sprach über die Schwierigkeiten, solche Fehler zu finden und wie man sie manuell mit den Google Chrome-Tools macht. Als nächstes untersuchte ich das
SeaLant- Tool, dessen Autor er ist. SeaLant automatisiert die Lecksuche durch Interaktion mit dem Chrome-Prozess mithilfe des Chrome DevTools-Protokolls. Der Bericht endete mit der Tatsache, dass, wenn die Seite zyklische Skripte ausführen kann (von einem Gerät mit einer Sitzung, ohne die Seite neu zu laden), Sie höchstwahrscheinlich durch Testen die meisten Speicherlecks beseitigen können.
5. Merkmale des visuellen Testens von Schnittstellen - Anton Usmansky, ein führender Entwickler von Gemini-Tools (ein visuelles Test-Tool) und Hermine (ein allgemeineres Tool der nächsten Generation, das Screenshot-Assertions ausführen kann).
Der Bericht ist nützlich für diejenigen, die über die Implementierung visueller Testwerkzeuge in ihren Projekten nachdenken. Diejenigen, die bereits Gemini und Hermine verwenden, könnten ebenfalls interessiert sein - es gibt ein Verständnis dafür, wie die Werkzeuge im Inneren angeordnet sind. An einigen Stellen befasst sich der Autor mit ziemlich grundlegenden Dingen.
6. Probleme in Selenium WebDriver - Alexey Barantsev.
Alexey sprach über die Probleme des Selen-Projekts und die Gründe für ihr Auftreten. Er teilte die Details der Mono-Repository-Baugruppe mit dem
Bazel- Sammler. Er ging auf das Thema der Sichtbarkeit von Elementen ein (im W3C WebDriver-Standard gibt es keine Operation, die prüft, ob ein Element sichtbar ist oder nicht) und erklärte, wie sich die Funktionen getProperty, getDomAttriubute und getAttribute unterscheiden.
Wenn Benutzer Probleme kennen, können sie Funktionen von Fehlern unterscheiden und in ihren Testprojekten effektive „Krücken“ entwickeln.
7. Rezepte für die Erstellung von Grund auf neu und die Entwicklung eines Lasttestsystems - Anatoly Plaskovsky.
Anatoly vertritt die Yandex.Money Performance Research Group. In seinem Bericht teilte er seine Praktiken mit, wie man den Bedarf an Leistungsstudien ermittelt, wo man Leute findet, die diese Aktivitäten durchführen, und wie man einen Forschungsprozess aufbaut. Der Autor konzentriert sich auf die Tatsache, dass Leistungsforschung! = Lasttests und dass nur Tests in der Produktion ein relevantes Ergebnis zeigen können. Gleichzeitig ist es möglich, Experimente ohne Probleme für Kunden durchzuführen, indem Testrouten und Daten ausgewählt, mögliche Ergebnisse des Szenarios überwacht und vorhergesagt werden.
Anatoly hat ein Telegramm-Chat-Loadland erstellt, in dem Lasttests besprochen werden und in dem Sie um Hilfe und Rat klopfen können.
8. Epische Fehler von Geräteherstellern - Valentine Wylsacom Petukhov.
Der erste Tag wurde durch den Bericht des berüchtigten Wylsacom abgeschlossen, der von der Öffentlichkeit mehrdeutig wahrgenommen wurde (gemessen am Chat der Teilnehmer am Heisenbag in einem Telegramm :)).
Für mich selbst habe ich dem Bericht über Betatests von Geräten und Anwendungen nichts Interessantes entnommen, aber vielleicht hat es den Fans gefallen. Der Diskussionsbereich war für das Foto vorgesehen, sodass PR ein Erfolg war.
9. Elegante Integrationstests des Microservice-Zoos mit TestContainers und JUnit 5 am Beispiel der globalen SMS-Plattform - Andrey Markelov.
Der Autor erzählte, wie Microservices in seinem Unternehmen mithilfe des Testontainers + Junit 5 + MockServer-Bundles getestet werden. Der Bericht klang interessant, aber ein solches Schema gilt nicht für eine große Anzahl von Mikrodiensten. Link zum
Quellcode.
10. Voyeurismus des Testers oder Wie die Überwachung von Benutzern Ihnen helfen wird - Antonina Khisametdinova.
Ein sehr interessanter Bericht, der sich jedoch mehr auf das Webdesign als auf das Testen bezieht. Es geht um UX-Praktiken und Fallstricke, die beim Entwerfen der Client-Oberfläche vermieden werden sollten.
Antonina identifizierte die Hauptfehler bei der Beobachtung von Benutzern in solchen UI-Lösungen wie Deaktivieren von Schaltflächen, Verwenden von Ladern, Tooltips, vertrauten Komponenten usw.
Erwähnenswert ist auch das grafische Design des Berichts mit intuitiven Beispielen aus realen Projekten (wie es sich für Berichte über UX gehört).
11. Testsysteme mit externen Abhängigkeiten: Probleme, Lösungen, Mountebank - Andrey Glazkov.
Der Autor sprach über die Entwicklung der Benetzungsstadien seiner Projekte. Berücksichtigt die Vor- und Nachteile des Rauchens auf Codeebene. Er teilte seine Erfahrungen mit, in welchen Fällen es gut ist, eine gefälschte Service-Implementierung zu erstellen. Wenn Sie jedoch möchten, dass gefälschte Dienste im laufenden Betrieb neu erstellt, Proxys und gleichzeitig Protokolle eingehender Anforderungen eingegeben werden, empfiehlt Andrey, sich das
Mountebank- Tool genauer anzusehen.
Die Hauptvorteile:
- mounteBank - arbeitet auf TCP-Ebene;
- JavaScript-Injektion;
- Zuverlässigkeit und Geschwindigkeit sofort einsatzbereit;
- ausgezeichnete Dokumentation;
- Unterstützung für Docker-Containerisierung.
Identifizierte Tool-Einschränkungen:
- externe Systeme mit Datenspeicherung;
- WebSocket - nicht unterstützt;
- Lasttests (> 150 U / s), Sie können jedoch einen Balancer verwenden.
12. Warum Profil-End-to-End-Tests mobiler Anwendungen - Vyacheslav Frolov.
In seinem Bericht sprach Vyacheslav über den Status von Autotests bei Badoo, nämlich wie sie das Problem der Parallelisierung von 1.500 mobilen UI-Tests lösten, deren Ausführung auf einem Simulator 30 Maschinenstunden dauert. Infolgedessen gelang es ihnen, ein Ergebnis von 30 Minuten zu erzielen, wodurch sie 80.000 Tests pro Tag durchführen konnten. Zusätzlich zu einer linearen Leistungssteigerung wurde eine Optimierung angewendet, um den Anwendungscache zu löschen, anstatt den Simulator neu zu starten. In dem Bericht wurden auch Profiler erwähnt und wie sie verwendet wurden, um spezielle Fälle von Engpässen in Tests zu erkennen: Beispielsweise lief die long_press () -Methode in ios 11.0 5 Sekunden lang und nach der Optimierung in einer Sekunde oder wie mithilfe des http-Headers -alive "Sie können vermeiden, die Verbindung wiederherzustellen, wodurch alle Tests auf einmal erheblich beschleunigt werden. Der Autor erklärte auch, wie die Profiler-Ergebnisse mit den Tools FlameGraph und FlameChart angezeigt werden.
13. Unit Tests: Von der Theorie zur Praxis - Vadim Pushtaev.
Der Autor teilt seine Erfahrungen bei der Entwicklung von UnitTests. Der Bericht bestand aus drei Teilen.
- Was wollen wir von UT → Regression (Code geändert, aktiviert), Einfluss auf die Architektur (Wenn Entwickler Tests schreiben, wird der Code besser), Verständnis (Umgang mit Legacy-Code);
- Prinzipien → Vadim erinnert sich, dass Theorie nicht so gut ist wie Praxis. Das Prinzip „Testen der Schnittstelle, nicht der Implementierung“ wurde abgelehnt, da die Implementierung viel Logik enthalten kann. Außerdem ist das Prinzip "Unit-Tests kein Testmechanismus". Er hält dies für eine Art Architekturtechnik, die leistungsstark und sehr nützlich ist, aber dies ist kein Mechanismus zur Überprüfung und Korrektheit des Codes.
- Implementierung → Eine Geschichte über die Techniken, die der Autor in der Arbeit verwendet (für jede Klasse gibt es eine Testklasse, die Erstellung eigener Matcher, die Verwendung externer Abhängigkeiten, falls erforderlich usw.)
14. Testen und Weinen mit dem Spring Boot Test - Kirill Tolkachev
Cyril beschloss, uns in die Welt von IoC, DI und Spring zurückzukehren und zu erklären, wie man Unit- und Komponententests mit JUnit 5 und SpringBoot schreibt.
Ein großes Plus dieses Berichts ist, dass der Sprecher die meisten Tests in Echtzeit geschrieben hat, d. H. demonstrierte deutlich den schrittweisen Prozess des Wickelns von Tests mit Federanmerkungen. Aufgrund der großen Menge an Code war es jedoch schwierig, alle gezeigten Techniken in meinen Kopf zu setzen. Cyril untersuchte Spring-Funktionen zum Arbeiten mit Profilen, Mock & Spy Beans sowie zum Festlegen von Kontextkonfigurationen. Für mich ist Spring ein ziemlich schweres Framework für solche Aufgaben, und nur erfahrene Benutzer können bei der Entwicklung von Komponententests nicht auf den Rechen treten.
15. Wir pumpen mobile Autotests - Ekaterina Bateeva.
In dem Bericht untersuchte der Autor das XCTest-Tool zur Automatisierung von iOS-Anwendungen. Das Duplizieren dieses Tools in anderen Projekten war unpraktisch.
Die folgenden Nachteile wurden nämlich identifiziert:
- schwer lesbare Starteinstellungen;
- schwierig zu konfigurierende Baugruppen;
- schwer in verschiedene Dienste zu integrieren;
- unpraktisch, um Screenshots zu verwalten;
- Das Konfigurieren von Testneustarts ist unpraktisch.
Als nächstes sprach Catherine über das Open-Source-
Fastlane- Framework, das ihre Probleme löste.
Zusammenfassung
Im Allgemeinen hat mir die Konferenz gefallen. Erhielt eine Ladung Emotionen und Antworten auf Fragen von Interesse. Während der BoF-Sitzung nahmen die meisten Teilnehmer ihre „Masken“ ab und führten hitzige Diskussionen im Rahmen von BoF-Themen. Kaffeepausen und Abendessen waren perfekt, es gab immer etwas zu essen. Ich möchte auch die Organisation der Veranstaltung erwähnen - das JUG.RU-Team macht Heisenbug jedes Mal besser und besser. Schließlich - gehen Sie zu Konferenzen, teilen Sie das erworbene Wissen und verbessern Sie Ihre Fähigkeiten!
PS: Ich danke Alexei Rumyantsev für die Teilnahme an der Vorbereitung des Artikels und Artem Eroshenko für das Videomaterial.