Les 6 et 7 décembre, la cinquième conférence Heisenbag s'est tenue à Moscou.
Son slogan est «Testing. Non seulement pour les testeurs! », Et pendant deux ans de visites régulières aux Heisenbags, moi (anciennement développeur Java, maintenant leader technique dans une petite entreprise qui n'avait jamais travaillé en AQ), j'ai réussi à apprendre beaucoup de tests et à en mettre beaucoup en œuvre dans notre équipe. Je veux partager un examen subjectif des rapports dont je me souviens cette fois.
Clause de non-responsabilité. Bien sûr, ce n'est qu'une petite fraction (8 sur 30) des rapports sélectionnés en fonction de mes préférences personnelles. Presque tous ces rapports sont en quelque sorte liés à Java et il n'y en a pas un seul sur le développement frontal et mobile. Dans certains endroits, je me permettrai une polémique avec le locuteur. Si vous êtes intéressé par une revue plus complète et neutre, par tradition elle devrait apparaître
sur le blog des organisateurs . Mais, peut-être, il sera intéressant pour quelqu'un de se renseigner sur ces rapports auxquels il n'a pas pu se rendre.
Les photos de l'article proviennent du twitter officiel de la conférence.Baruch Sadogursky. Nous avons DevOps. Tirons tous les testeurs
(Sur la photo - le battage médiatique lorsque Baruch a distribué le livre Liquid Software )Ceux qui sont impliqués dans Java et participent aux conférences du groupe JUGRU, Baruch Sadogursky n'a pas besoin d'être présenté. Cependant, il s'est produit pour la première fois au Heisenbug.
En un mot - c'était un rapport d'examen sur les principales idées de DevOps. Le public a toujours besoin de tels rapports, car lorsqu'on lui demande «Donnez la définition de DevOps» au public, les gens répondent tout d'abord «C'est une telle personne ...»
Mais même ceux qui ont déjà appris quelque chose sur ce sujet, il sera très intéressant de se renseigner sur les études de l'association DORA
devops-research.com , qui a reçu des pourcentages de variétés de travaux manuels en équipes aux performances différentes. Et à propos de la courbe reliant la vitesse de livraison et la qualité (à un moment donné, la vitesse diminue, car nous avons besoin de temps pour "mieux tester", mais au fur et à mesure que l'équipe se développe, la corrélation devient directe):
Bien que le titre du rapport soit provocateur et que le rapport soit marqué dans la liste «brûlera», son contenu était, à mon avis, assez courant. Il ne s'agissait bien sûr pas de licenciement de testeurs dans les conditions de la transformation Devops, mais d'un changement dans la nature du travail des testeurs.
Alan Page et Nikolai Alimenkov ont beaucoup parlé de ces choses il y a un an. L'évolution des rôles et le développement «horizontal» des compétences en T ont été discutés il y a un an lors de la table ronde «
ce qu'un testeur devrait savoir en 2018 ».
«Bien sûr, si vous ne voulez pas changer, il y a du travail pour vous, quoique pas si intéressant. Jusqu'à présent, il y a encore du travail pour ceux qui veulent prendre en charge des systèmes écrits en COBOL dans les années 70 », a déclaré Baruch.
Artyom Eroshenko. Besoin de refactoriser un projet? Ayez une IDÉE!
Artyom connaît les participants de Heisenbag avec des rapports sur le système de rapport Allure (par exemple,
voici son rapport sur les opportunités Allure paru en 2018 lors du précédent Heisenbug à Saint-Pétersbourg). Allure lui-même est né dans le contexte de projets avec des milliers, des dizaines de milliers et même plus de centaines de milliers de tests et est conçu pour simplifier l'interaction entre les développeurs et les testeurs. Il a la capacité de lier des tests à des ressources externes telles que des systèmes de billetterie et des validations dans le système de contrôle de version. Dans notre micro-équipe, alors que le nombre de tests n'était que de dizaines, nous avons complètement géré les moyens standard. Mais comme le nombre de tests dans l'un des produits a atteint 700 et que la tâche globale était de créer des rapports de haute qualité pour les clients, j'ai commencé à regarder vers Allure.
Cependant, ce rapport n'était pas sur Allure, bien que sur lui aussi.
Artyom a convaincu le public qu'écrire des plugins pour IntelliJ IDEA est une activité simple et fascinante. Pourquoi cela serait-il nécessaire? Pour automatiser la modification de code en masse. Par exemple, pour traduire un grand nombre de codes sources de JUnit4 en JUnit5. Ou de l'utilisation d'Allure 1 à Allure 2. Ou d'automatiser le balisage des tests avec communication avec le système de ticking.
Ceux qui travaillent avec IDEA savent quelles astuces il peut faire avec du code (par exemple, traduire automatiquement du code en utilisant des boucles for en du code en utilisant Java Streams et vice versa, ou traduire instantanément Java en Kotlin). Plus il était intéressant de voir comment s'ouvrait le voile du secret sur les transformations de code dans IDEA, nous sommes invités à y participer et à créer nos propres plugins pour nos besoins uniques. La prochaine fois, lorsque je devrai faire quelque chose avec une grande base de code, je rappellerai ce rapport et verrai comment il peut être automatisé à l'aide d'un plug-in générique dans IDEA.
Kirill Merkushev. Projet Java et Reactor - qu'en est-il des tests?
Ce rapport, il me semble, aurait pu avoir lieu lors des conférences Joker ou JPoint Java. Kirill a
expliqué comment il utilise le framework
projectreactor.io dans une architecture de microservices avec un seul journal des événements (Kafka), un peu sur l'essence du codage sur les «flux réactifs», y compris comment les applications utilisant ce framework peuvent être déboguées et testées.
La vie pousse également notre équipe à utiliser l'architecture avec un seul journal des événements, et nous examinons également Kafka. Certes, pour les événements de streaming, nous expérimentons l'API Kafka Streams (où, il me semble, plus de choses comme le traitement avec état sont implémentées de manière transparente pour le développeur), et non Reactor. Cependant, comme c'est toujours le cas avec les nouvelles technologies, le «rake» et les «pièges» ne sont pas connus à l'avance. Il était donc important d'écouter l'histoire d'un spécialiste qui travaille déjà avec la technologie.
Leonid Rudenko. Gérer un cluster Selenoid avec Terraform
Si le rapport précédent rappelait une conférence JPoint, alors celui-ci concerne certainement
DevOops . Leonid a expliqué comment utiliser les spécifications Terraform pour augmenter et configurer un cluster Selenoid. À propos de ce que Selenoid lui-même était, il y
avait un rapport sur Heisenbug de l'année dernière - c'est un système distribué riche qui fonctionne comme un service élastique et vous permet d'exécuter un grand nombre de tests Selenium dans divers navigateurs. Comme tout système qui nécessite un déploiement sur plusieurs machines, l'installation manuelle de Selenoid est difficile. Ici, les systèmes de configuration en tant que code modernes viennent à la rescousse.
Leonid a fait un aperçu assez détaillé des capacités de Terraform - un système qui n'était probablement pas familier à la plupart des spectateurs, mais en fait déjà bien connu de DevOps-automation (par exemple, lors de la conférence Devoops-2018, Anton Babenko a
publié un excellent rapport sur les meilleures pratiques pour créer et maintenir le code sur Terraform). De plus, il a été montré comment utiliser les scripts Terraform pour décrire les paramètres des conteneurs Docker avec Selenoid pour chacune des machines du cluster et les paramètres des machines virtuelles du cluster elles-mêmes.
Bien que le cas spécifique examiné par Leonid soit certainement en mesure de faciliter la tâche de déploiement de Sélénoïde, je ne suis pas d’accord avec l’orateur sur tout. Essentiellement, il utilise Terraform pour deux tâches différentes: créer des ressources et les configurer. Et cela conduit au fait que Leonid est obligé d'exécuter Terraform une fois pour créer des machines virtuelles et une fois de plus pour chacune des machines virtuelles pour y élever des conteneurs Docker. À mon avis, Terraform, qui résout bien le problème de la création de ressources, ne résout pas très bien le problème de configuration. Il serait possible d'éviter la multiplication des projets terraform et leur lancement répété en utilisant des systèmes de configuration spéciaux, par exemple Ansible, ou d'autres solutions.
Mais en général, en tant que «programme éducatif» pour les testeurs dans le domaine de l'infrastructure comme code, ce rapport est très utile.
Andrey Markelov. Test d'intégration élégant du zoo de microservices avec TestContainers et JUnit 5 en utilisant l'exemple de la plate-forme SMS globale
Et encore une fois sur les microservices! Cette fois, la conversation a porté sur la façon d'exécuter des tests qui nécessitent le lancement et l'interaction de plusieurs services en même temps. JUnit5 avec son
système d'extension et le cadre bien connu (et excellent) TestContainers ont été proposés comme base de la solution (voir, par exemple,
le rapport de l'année dernière de Sergey Egorov ).
Si vous écrivez quelque chose en Java et que vous ne savez toujours pas ce qu'est TestContainers, je vous recommande vivement de l'étudier. TestContainers permet, en utilisant la technologie Docker, directement dans le code de test de récupérer de vraies bases de données et d'autres services, de les connecter sur le réseau et, par conséquent, d'effectuer des tests d'intégration dans l'environnement qui a été créé au moment où les tests ont été lancés et détruits immédiatement après. Dans le même temps, tout fonctionne directement à partir du code Java, se connecte en tant que dépendance Maven et ne nécessite pas d'installer autre chose que Docker sur la machine / le serveur CI du développeur. Nous utilisons TestContainers depuis plus d'un an maintenant.
Andrei a montré un exemple assez impressionnant de la façon dont vous pouvez spécifier la configuration de l'environnement de test pour les tests de bout en bout à l'aide des extensions JUnit5, des annotations personnalisées et des TestContainers. Par exemple, écrire des annotations sur votre test (code conditionnel)
@Billing @Messaging
on peut, relativement parlant, écrire
@Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...}
dans les paramètres dont les interfaces Java seront passées à travers lesquelles vous pouvez communiquer avec des services réels élevés (inaperçus par le développeur de test) dans des conteneurs.
Ces exemples sont très élégants. Pour moi, en tant qu'utilisateur actif de TestContainers et JUnit 5, ils sont compréhensibles et relativement faciles à implémenter.
Mais en général, avec cette approche, la grande question reste non résolue, liée au fait que la façon de configurer les systèmes de test et de production est fondamentalement différente.
La mise en œuvre de versions rapides en production sans crainte de tout casser n'est possible que si pendant les tests de bout en bout non seulement le système entier a été testé, mais aussi la manière de le configurer. Si nous exécutions à plusieurs reprises le script de déploiement du système pendant le processus de développement et de test, nous n'aurions aucun doute que ce script fonctionnerait même lorsqu'il est lancé en production. Le rôle du code qui configure l'environnement de test dans l'exemple d'Andrey est effectué par des annotations. Mais en production, nous présentons le système en utilisant un code complètement différent - Ansible, Kubernetes, n'importe quoi - qui n'est impliqué en aucune façon dans de tels tests de système. Et cela limite ces tests, qui ne sont pas complètement de bout en bout.
Andrey Glazkov. Tester des systèmes avec des dépendances externes: problèmes, solutions, Mountebank
Pour ceux pour qui le sujet de ce rapport est pertinent, je vous recommande vivement de regarder également une
brillante présentation d'Andrei Solntsev sur une approche de principe pour tester les systèmes qui dépendent de services externes. Solntsev parle de manière très convaincante de la nécessité d'utiliser des simulations de système externes pour des tests complets. Et Andrei Glazkov dans son rapport décrit l'un des systèmes pour un tel mouillage - Mountebank, écrit en NodeJS.
Vous pouvez lever Mountebank en tant que serveur et «former» les réponses aux demandes sur le réseau d'une manière similaire à la façon dont nous «formons» les simulations d'interface lors de l'écriture des tests unitaires. La seule différence est qu'il s'agit d'une maquette d'un service réseau. Un cas curieux d'utilisation de Mountebank est la possibilité de l'utiliser comme proxy - en envoyant certaines requêtes à un véritable système externe.
Il convient de noter ici que je recommanderais que les développeurs Java (et Andrei en conviennent dans la zone de discussion) se tournent également vers la bibliothèque WireMock, qui est créée en Java et peut être exécutée en mode embarqué, c'est-à-dire directement à partir des tests sans installer aucun Soit des services à la machine du développeur ou au serveur CI (bien qu'il puisse également fonctionner comme un serveur autonome). Comme Mountebank, WireMock prend en charge le mode proxy. Nous avons une expérience positive avec WireMock.
L'avantage de Mountebank, cependant, est la prise en charge de protocoles de niveau inférieur (WireMock ne fonctionne que pour HTTP) et la possibilité de travailler dans un «zoo» de différentes technologies (il existe des bibliothèques pour différentes langues pour Mountebank).
Kirill Tolkachev. Tester et pleurer avec le Spring Boot Test
Et encore Java, microservices et JUnit 5. Kirill est un autre orateur des conférences Joker et JPoint, bien connu de la communauté Java, qui a parlé pour la première fois à Heisenbug.
Ce rapport est une version modifiée du rapport
Spring Curse de l'an dernier, avec des exemples modifiés pour JUnit5 et Spring Boot 2. Divers problèmes pratiques liés à la configuration des tests Spring Boot dans les tests de composants / microservices sont examinés en profondeur. Par exemple, j'ai été impressionné par l'exemple de l'utilisation de
@SpringBootConfiguration StopConfiguration vide au bon endroit dans l'arborescence source pour arrêter le processus d'analyse de la configuration, ainsi que par la possibilité d'utiliser
@MockBean et
@SpyBean au lieu de
@SpyBean . Comme d'autres rapports de Cyril et Evgeny Borisov, il s'agit d'un matériau auquel il est logique de revenir dans le processus d'utilisation pratique du Spring Framework.
Andrey Karpov. Que peuvent faire les analyseurs statiques, ce que les programmeurs et les testeurs ne peuvent pas faire
L'analyse de code statique est une bonne chose. Selon les canons de la livraison continue, ce devrait être la toute première phase du pipeline de livraison, filtrant le code avec des problèmes qui peuvent être détectés en "lisant" le code. L'analyse statique est bonne car elle est rapide (beaucoup plus rapide que les tests), et aussi bon marché (elle ne nécessite pas d'effort supplémentaire de la part de l'équipe sous forme de tests d'écriture: toutes les vérifications ont déjà été écrites par les auteurs de l'analyseur).
Andrey Karpov, l'un des fondateurs du projet PVS-Studio (familier aux lecteurs Habr avec son
blog ) a construit un rapport sur des exemples de bogues dans l'analyse de code de produits connus qui ont été trouvés en utilisant PVS-Studio. PVS Studio lui-même est un produit polyglotte, il prend en charge C, C ++, C # et, plus récemment, Java.
Malgré le fait que les exemples ci-dessus étaient intéressants et l'utilité de leur analyse statique est évidente, à mon avis, le rapport d'Andrey avait des défauts.
Premièrement, le rapport a été construit uniquement sur la considération du produit PVS-Studio (pour lequel, selon l'orateur, «le prix moyen est de 10 000 $»). Mais il convient de mentionner qu'en fait, dans de nombreux langages, il existe de nombreux systèmes d'analyse statique OpenSource développés. En Java seul - le Checkstyle et SpotBugs gratuits (le successeur du projet FindBugs gelé), ainsi que l'analyseur IntelliJ IDEA, qui peut être exécuté séparément de l'IDE et recevoir un rapport, ont fait d'énormes progrès.
Deuxièmement, en parlant d'analyse statique, il me semble qu'il vaut toujours la peine de mentionner les limites fondamentales de cette méthode. Tout le monde n'est pas passé par la théorie des algorithmes à l'université et connaît bien le «problème de fermeture», par exemple.
Et enfin, les problèmes d'introduction de l'analyse statique dans la base de code existante n'ont pas été soulevés du tout, ce qui empêche encore beaucoup d'utiliser régulièrement des analyseurs sur des projets. Par exemple, nous avons exécuté l'analyseur sur un grand projet hérité et trouvé 100 500 vorings. Il n'y a pas de temps et d'efforts pour les corriger directement et changer massivement quelque chose dans le code est un risque. Que faire avec cela, comment faire fonctionner l'analyse statique comme une porte de qualité? Ce problème a été discuté dans la zone de discussion avec Andrei, mais cette question n'a pas été prise en compte dans le rapport lui-même.
En général, je souhaite à Andrey et à son équipe plein succès. Leur produit est intéressant et l'idée d'occuper sa niche dans ce domaine est très audacieuse.
***
Je ne dirai peut-être rien sur les discours finaux des premier et deuxième jours: ce sont tous les deux des émissions de droits d'auteur qu'il suffit de regarder. En parler, c'est comme raconter des mots, par exemple, une performance d'un groupe de rock.
Dans mon rapport d'il y a un
an, j'ai déjà essayé de transmettre l'atmosphère générale de la conférence et parlé de ce qui se passe dans les zones de discussion, au déjeuner et à la fête, donc je ne vais pas me répéter.
En conclusion, je voudrais remercier les organisateurs pour une autre conférence magnifiquement tenue. Si je comprends bien, l'intérêt pour la conférence a légèrement dépassé les attentes, il y a eu une surréservation et même tout le monde n'avait pas assez de souvenirs. Mais pour sûr, tout le monde avait des choses plus importantes: rapports intéressants, espace de discussion, nourriture et boissons. J'ai hâte de nouvelles rencontres!