Dans cet article, je veux partager une revue de 15 rapports de la conférence de Heisenbug, pour vous dire ce qui était intéressant sur les stands des entreprises, et aussi pour partager du matériel vidéo du rapport d'Artyom Eroshenko sur la création de plugins d'action pour IntelliJ IDEA qui vous aideront à changer rapidement le code du projet de test.
Informations sur HeisenBug
Heisenbug - Conférence technique pour les spécialistes des tests. Fondamentalement, il est intéressant pour les testeurs, les ingénieurs de développement logiciel en test, les spécialistes des tests automatisés et en charge. Les organisateurs sont l'équipe
JUG.RU , derrière laquelle se trouvent des conférences telles que Joker, HolyJS, SmartData, DevOops, DotNext, Mobius.
Lieu
La cinquième conférence s'est tenue à l'hôtel Slavyanskaya Radisson, station de métro Kievskaya, Moscou. À l'approche de l'hôtel, une bannière électronique avec le logo de la conférence était visible. De plus, à l'entrée du hall de l'hôtel, le participant était accompagné de panneaux indiquant les comptoirs d'enregistrement et l'armoire. Il est impossible de se perdre. L'inscription des participants et des conférenciers a eu lieu au rez-de-chaussée, dans le hall principal de la conférence, il y avait des stands de partenaires, des salles de conférence, des salles avec une pause-café et des déjeuners. Le niveau des gardes de sécurité satisfait, de sorte que les «lapins clandestins» ne devaient pas obtenir. Au total, l'événement a réuni environ 500+ participants, dont la plupart se sont inscrits deux semaines avant le début.
Le programme
Le programme peut être trouvé
ici . Je tiens à noter que
JUG.RU s'efforce toujours de rendre le programme pratique, sans eau supplémentaire et avec des experts étrangers bien connus. Les rapports sont divisés en symboles:
Si c'est la première fois que vous envisagez de devenir conférencier chez Heisenbag, lisez
la note du conférencier - elle contient beaucoup d'informations utiles.
Communication et bénévolat
Afin que les participants ne manquent pas quelque chose d'important lors de la conférence, une chaîne de télégrammes et un chat télégramme ont été organisés. Soit dit en passant, dans ce dernier, ils cherchaient des volontaires pour regarder des vidéos, pour lesquelles ils ont donné un billet de conférence gratuit.
Si vous décidez de devenir bénévole, indiquez votre décision aux organisateurs le plus tôt possible. La préparation de l'événement se fait bien avant la conférence. Sous réserve de disponibilité, vous serez affecté à l'équipe.
Stands d'entreprise
Cette fois, la conférence a présenté plus d'une douzaine de stands de grandes sociétés informatiques, telles que la Deutsche Bank, Alfa-Bank, Raiffeisen, Badoo, Luxoft, SKB Kontur, Gett, etc. Chacune des sociétés a abordé l'organisation des interactions avec les participants à leur manière. , donc entre les représentations, il ne fallait pas s'ennuyer. Il a été possible de résoudre des problèmes pour un petit souvenir mémorable, de jouer à des jeux vidéo et de société et de participer à la loterie.
Raiffeisen a proposé de passer par une quête en ligne avec une solution à toutes sortes de puzzles, également les connaisseurs de classiques sans âge pourraient jouer à Mortal Kombat 3 sur Sega. Les collègues d'Alfa-Bank ont créé un robot télégramme avec des tâches, ainsi qu'un grand nombre de Lego Mindstorms joués à la loterie. Je tiens à féliciter le stand de la Deutsche Bank, où les développeurs en communication en direct ont donné des tâches et participé à la discussion, contrairement à tous les autres stands, où ils n'ont vérifié que les réponses.
De nombreuses entreprises chassent discrètement des spécialistes, distribuant des brochures décrivant les postes vacants (pas tout de même pour s'engager dans des œuvres caritatives).
Présentation des rapports
1. Nous avons DevOps. Tirons tous les testeurs - Baruch Sadogursky.
La conférence a été ouverte par Baruch Sadogursky, défenseur des développeurs de JFrog, un conférencier bien connu lors de conférences liées à Java et Devops. Dans le rapport, Baruch a abordé les problèmes de qualité des logiciels face aux versions fréquentes, qui sont causées par des demandes commerciales en constante augmentation, la complexité des tests de code en raison d'une architecture médiocre et la modernisation du rôle du testeur dans les équipes Agiles modernes. Le reportage était intéressant à écouter du début à la fin, beaucoup d'humour, des faits intéressants et des comparaisons.
Eh bien, les principales idées du rapport peuvent être regroupées dans une diapositive, qui illustre que les tests d'automatisation et les pratiques DevOps réduisent les coûts de temps des processus de routine et vous permettent de consacrer plus de temps à la mise en œuvre de nouvelles tâches.
2. Besoin de refactoriser un projet? Il y a IDEA! - Artem Eroshenko.
Artyom dans son rapport a parlé de la création de plug-ins d'
actions pour IntelliJ IDEA, qui vous aideront à changer rapidement le code du projet de test.
Il a donné une explication des principales classes (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager), qui sont le point d'entrée des Plugin Actions.
Considéré comment résoudre les tâches suivantes:
a) Ce qui est automatisé sur le projet et ce qui ne l'est pas. Synchronisation automatique avec Jira.
Selon le texte d'annotation, @DisplayName est allé à Jira, a reçu les tickets nécessaires et a supprimé toutes les connexions nécessaires à l'aide de @TmsLink.
b) Apposez automatiquement @Tags à partir du contexte Jira.
Il y a certaines étiquettes dans le
ticket de régression favori . Nous allons au test, il y a des annotations @TmsLink, nous utilisons le plugin et nous avons de nouvelles annotations @Tags, puis avec l'aide de Junit nous pouvons exécuter des tests sur ces balises.
c) Qu'est-ce qui est vérifié dans les tests?
Il y a un autotest, il y a des étapes, nous exportons et nous avons des étapes dans les tests. Toujours dans la vidéo, il y a un exemple pour deux tests.
Artyom a également montré comment passer rapidement d'Allure 1 à Allure 2.
Un rapport très pratique pour ceux qui envisagent d'optimiser le processus d'écriture du code. Le code source des plugins peut être trouvé
ici .
3. Projet Java et Reactor? - Mais qu'en est-il des tests? - Kirill Merkushev.
Cyril a partagé son expérience dans le développement de la startup médicale internationale Vivy. Il a expliqué comment les problèmes d'évolutivité d'un système monolithique ont été résolus à l'aide de microservices et de la bibliothèque Reactor. Une grande attention a été accordée à cette bibliothèque, à ses principes de base, aux approches de test des systèmes réactifs, aux fonctionnalités de tueur (telles que les points de contrôle et les journaux dans la chaîne de demande, les crochets et les demandes répétées (réessayer).
Personnellement, je ne m'occupais pas de tester des systèmes réactifs, donc pour moi c'était nouveau et intéressant.
4. Comme nous avons écrit le framework Sealant pour la recherche de fuites de mémoire dans JS , Sergey Dokuchaev.
Cette présentation concerne les fuites de mémoire (objets accessibles à partir du code mais qui ne sont plus nécessaires) sur les applications Web à page unique. Sergey a défini la tâche de trouver automatiquement toutes les fuites de mémoire critiques dans la version publiée du produit. Il a parlé des difficultés à trouver de telles erreurs et comment le faire manuellement à l'aide des outils Google Chrome. Ensuite, j'ai examiné l'outil
SeaLant , dont il est l'auteur. SeaLant automatise la détection des fuites en interagissant avec le processus Chrome à l'aide du protocole Chrome DevTools. Le rapport s'est terminé avec le fait que si la page peut exécuter des scripts cycliques (à partir d'un appareil, avec une session, sans recharger la page), alors très probablement, en les testant, vous pouvez vous débarrasser de la plupart des fuites de mémoire.
5. Caractéristiques des tests visuels des interfaces - Anton Usmansky, un développeur leader d'outils Gemini (un outil de test visuel) et Hermione (un outil de nouvelle génération, plus polyvalent, qui peut effectuer des assertions de capture d'écran).
Le rapport est utile pour ceux qui envisagent d'implémenter des outils de test visuel dans leurs projets. Ceux qui utilisent déjà Gemini et Hermione peuvent également être intéressés - cela permet de comprendre comment les outils sont disposés à l'intérieur. À certains endroits, l'auteur traite de choses assez basiques.
6. Problèmes dans Selenium WebDriver - Alexey Barantsev.
Alexey a parlé des problèmes du projet Selenium et des raisons de leur apparition. Il a partagé les détails de l'assemblage mono-référentiel à l'aide du collecteur
Bazel . Il a abordé le sujet de la visibilité des éléments (dans la norme W3C WebDriver, aucune opération ne vérifie si un élément est visible ou non) et a expliqué en quoi les fonctions getProperty, getDomAttriubute, getAttribute diffèrent.
La connaissance des problèmes permettra aux utilisateurs de distinguer les fonctionnalités des bogues et de développer des «béquilles» efficaces dans leurs projets de test.
7. Recettes pour créer à partir de zéro et développement d'un système de test de charge - Anatoly Plaskovsky.
Anatoly représente le groupe de recherche sur la performance Yandex.Money. Dans son rapport, il a partagé ses pratiques sur la façon de déterminer le besoin d'études de performance, où trouver des personnes pour mener ces activités et comment construire un processus de recherche. L'auteur se concentre sur le fait que la recherche de performances! = Test de charge, et que seuls les tests de production peuvent montrer un résultat pertinent. Dans le même temps, il est possible de mener des expériences sans problème pour les clients en choisissant des itinéraires et des données de test, en surveillant et en prédisant les résultats possibles du scénario.
Anatoly a créé un espace de chargement de discussion par télégramme, qui traite des tests de charge et où vous pouvez frapper pour obtenir de l'aide et des conseils.
8. Epic échoue des fabricants d'appareils - Valentine Wylsacom Petukhov.
La première journée a été clôturée par le rapport du célèbre Wylsacom, qui a été perçu de manière ambiguë par le public (à en juger par le chat des participants à Heisenbag dans le télégramme :)).
Pour ma part, je n'ai rien retiré d'intéressant du rapport sur les tests bêta des appareils et des applications, mais peut-être que les fans l'ont aimé. La zone de discussion était alignée pour la photo, donc les relations publiques ont été un succès.
9. Élégant test d'intégration du zoo de microservices utilisant TestContainers et JUnit 5 en utilisant l'exemple de la plate -
forme SMS mondiale - Andrey Markelov.
L'auteur a expliqué comment les microservices sont testés dans son entreprise à l'aide du bundle Testontainers + Junit 5 + MockServer. Le rapport semblait intéressant, mais un tel schéma n'est pas pour un grand nombre de microservices. Lien vers le
code source.
10. Voyeurisme du testeur, ou comment la surveillance des utilisateurs vous aidera - Antonina Khisametdinova.
Un rapport très intéressant, bien que plus lié à la conception web qu'aux tests. Il parle des pratiques UX et des pièges à éviter lors de la conception de l'interface client.
Antonina a identifié les principales erreurs lors de l'observation des utilisateurs dans des solutions d'interface utilisateur telles que la désactivation des boutons, l'utilisation de chargeurs, d'infobulles, de composants familiers, etc.
Il convient également de noter la conception graphique du rapport avec des exemples intuitifs de projets réels (comme il convient aux rapports sur UX).
11. Tests de systèmes avec des dépendances externes: problèmes, solutions, Mountebank - Andrey Glazkov.
L'auteur a évoqué l'évolution des étapes de mouillage sur ses projets. Considéré les avantages et les inconvénients du moking au niveau du code. Il a partagé son expérience dans quels cas il est bon de créer une implémentation de faux services. Mais si vous voulez que les faux services soient reconstruits à la volée, les procurations et en même temps les journaux des demandes entrantes seront entrés, alors Andrey recommande de regarder de plus près l'outil
Mountebank .
Les principaux avantages:
- mounteBank - fonctionne au niveau TCP;
- Injection JavaScript;
- fiabilité et vitesse hors de la boîte;
- excellente documentation;
- prise en charge de la conteneurisation de docker.
Limitations des outils identifiées:
- systèmes externes avec stockage de données;
- WebSocket - non pris en charge;
- tests de charge (> 150 rps), mais vous pouvez utiliser un équilibreur.
12. Pourquoi profiler les tests de bout en bout des applications mobiles - Vyacheslav Frolov.
Dans son rapport, Vyacheslav a parlé de l'état des autotests à Badoo, à savoir comment ils ont résolu le problème de la parallélisation de 1500 tests d'interface utilisateur mobile, qui prennent 30 heures de machine pour fonctionner sur un simulateur. En conséquence, ils ont réussi à obtenir un résultat de 30 minutes, ce qui leur a permis d'effectuer 80 000 tests par jour. En plus d'une augmentation linéaire de la puissance, une optimisation a été appliquée pour vider le cache de l'application au lieu de redémarrer le simulateur. Les profileurs ont également été mentionnés dans le rapport, et comment ils ont été utilisés pour détecter des cas particuliers de goulots d'étranglement dans les tests: par exemple, la méthode long_press () dans ios 11.0 a fonctionné pendant 5 secondes, et après l'optimisation, elle a commencé à s'exécuter dans une seconde, ou comment à l'aide de l'en-tête http -alive "vous pouvez éviter de rétablir la connexion, accélérant ainsi considérablement tous les tests à la fois. L'auteur a également expliqué comment afficher les résultats du profileur à l'aide des outils FlameGraph et FlameChart.
13. Tests unitaires: de la théorie à la pratique - Vadim Pushtaev.
L'auteur partage son expérience dans l'élaboration de tests unitaires. Le rapport se composait de trois parties.
- Que voulons-nous de UT → Régression (Changement de code, vérifié), Influence sur l'architecture (Lorsque les développeurs écrivent des tests, le code s'améliore), Compréhension (pour gérer le code hérité);
- Principes → Vadim rappelle que la théorie n'est pas aussi bonne que la pratique. Rejeté le principe de «tester l'interface, pas l'implémentation», car il peut y avoir beaucoup de logique dans l'implémentation. De plus, le principe «les tests unitaires n'est pas un mécanisme de test». Il considère cela comme une sorte de technique architecturale, puissante et très utile, mais ce n'est pas un mécanisme de vérification et d'exactitude du code.
- Implémentation → Une histoire sur les méthodes techniques que l'auteur utilise dans le travail (pour chaque classe il y a une classe de test, la création de leurs propres joueurs, l'utilisation de dépendances externes, si nécessaire, etc.).
14. Tester et pleurer avec le Spring Boot Test - Kirill Tolkachev
Cyril a décidé de nous replonger dans le monde de l'IoC, de la DI et de Spring et de nous expliquer comment écrire des tests unitaires et de composants à l'aide de JUnit 5 et SpringBoot.
Un gros avantage de ce rapport est que le locuteur a écrit la plupart des tests en temps réel, c'est-à-dire a clairement démontré le processus étape par étape de l'emballage des tests avec des annotations Spring. Cependant, en raison de la grande quantité de code, il était difficile de mettre toutes les techniques présentées dans ma tête. Cyril a passé en revue les fonctionnalités de Spring pour travailler avec des profils, Mock & Spy Beans, ainsi que pour définir des configurations de contexte. Quant à moi, Spring est un framework assez lourd pour de telles tâches et seuls les utilisateurs expérimentés ne pourront pas marcher sur le râteau lors du développement de tests unitaires.
15. Nous pompons des autotests mobiles - Ekaterina Bateeva.
Dans le rapport, l'auteur a examiné l'outil XCTest pour automatiser les applications iOS. Dupliquer cet outil sur d'autres projets n'était pas pratique.
À savoir, les inconvénients suivants ont été identifiés:
- difficile à lire les paramètres de démarrage;
- difficile à configurer des assemblages;
- difficile à intégrer avec divers services;
- gênant pour gérer les captures d'écran;
- gênant pour configurer les redémarrages de test.
Ensuite, Catherine a parlé du framework open-source
Fastlane , qui a résolu leurs problèmes.
Résumé
En général, j'ai aimé la conférence. Reçu une charge d'émotions et des réponses aux questions d'intérêt. Lors de la session BoF, la plupart des participants ont enlevé leurs «masques» et ont eu des discussions animées dans le cadre des sujets BoF. Les pauses café et les dîners étaient parfaits, il y avait toujours quelque chose à manger. Je veux aussi noter l'organisation de l'événement - l'équipe JUG.RU à chaque fois rend Heisenbug de mieux en mieux. Enfin - allez à des conférences, partagez les connaissances acquises et améliorez vos compétences!
PS: J'exprime ma gratitude à Alexei Rumyantsev pour sa participation à la préparation de l'article et à Artem Eroshenko pour le matériel vidéo.