Comment tester dans AutoCar: MindMap, analyse de code statique et MockServer

Salut Je veux vous dire comment les tests fonctionnent dans le projet Autotech , un service d'inspection automobile de VIN. Sous la coupe - sur les outils que nous utilisons pour tester les exigences, la planification du sprint, le fonctionnement du processus de test dans notre projet.

MindMap pour les tâches de toilettage

Nous utilisons Scrum dans l'Auto Center, car c'est la méthodologie la plus efficace pour nos tâches. Chaque semaine, nous organisons des réunions au cours desquelles nous hiérarchisons, déterminons la complexité, décomposons les tâches du backlog et définissons la définition de prêt et la définition de terminé pour chacune des tâches (vous pouvez en lire plus dans ce merveilleux article ). Ce processus est appelé nettoyage du backlog.

Pour un nettoyage efficace, toutes les dépendances doivent être prises en compte. Savoir comment la mise en œuvre de la tâche peut affecter négativement le projet. Comprenez quelles fonctionnalités vous devez prendre en charge et lesquelles couper. Peut-être, dans le processus de mise en œuvre de la tâche, l'API pour les partenaires peut souffrir, ou vous devez simplement vous rappeler d'implémenter des mesures permettant de comprendre l'efficacité de l'entreprise. Avec le développement de tout projet, il y a de plus en plus de telles dépendances, et leur prise en compte devient de plus en plus difficile. C'est mauvais: il est important pour l'équipe d'assistance de découvrir toutes les fonctionnalités à temps. Et parfois, les innovations doivent être coordonnées avec le service marketing.

En conséquence, j'ai proposé une solution basée sur MindMap, qui reflétait presque toutes les dépendances pouvant affecter le DoD, le DoR et l'évaluation des tâches.



L'avantage de cette approche est une représentation visuelle de toutes les dépendances possibles dans un style hiérarchique, ainsi que des chignons supplémentaires sous forme d'icônes, de sélection de texte et de branches multicolores. Toute l'équipe a accès à cette MindMap, qui vous permet de maintenir la map à jour. J'ai étendu le blanc d'une telle carte, qui peut être considérée comme un point de repère, ici - le melon . (Je réserverai tout de suite qu'il ne s'agit que d'une ligne directrice, et il est très douteux d'utiliser cette carte pour vos tâches sans finaliser le projet.)

Analyse de code statique et linty pour Go

Dans notre projet, un assez grand nombre de code golang, et afin que le style de code réponde à certaines normes, il a été décidé d'appliquer une analyse de code statique. À propos de ce que c'est, il y a un excellent article sur Habré.
Nous voulions intégrer l'analyseur dans le processus CI, de sorte qu'à chaque build du projet, l'analyseur démarre, et selon les résultats de la vérification, la build se poursuivait ou plantait avec des erreurs. En général, l'utilisation de gometalinter comme étape de build distincte dans Teamcity serait une bonne solution, mais l'affichage des erreurs dans les journaux de build n'est pas très pratique.
Nous avons continué à rechercher et trouver le Linty Bot, développé dans le cadre du hackathon Avito par Artemy Flaker Ryabinkov.



Il s'agit d'un bot qui surveille le code du projet dans notre système de contrôle de version et lance un analyseur de code diff à chaque demande d'extraction. Si une erreur se produit pendant l'analyse, le bot envoie un commentaire à ce PR à la ligne de code souhaitée. Ses avantages sont la vitesse de connexion au projet, la vitesse de travail, les commentaires sur les demandes de tirage et l'utilisation du linter Gometalinter plutôt populaire, qui contient déjà par défaut toutes les vérifications nécessaires.

MockServer et comment obtenir des services pour donner ce dont ils ont besoin

La section suivante concerne la stabilité du test. Un concessionnaire automobile est extrêmement dépendant des sources de données (elles proviennent de concessionnaires, de services gouvernementaux, de stations-service, de compagnies d'assurance et d'autres partenaires), mais leur inopérabilité ne peut pas être la base pour refuser de réaliser des tests.

Nous devons vérifier l'assemblage des rapports à la fois aux sources de travail et à leur inopérabilité. Jusqu'à récemment, nous utilisions de vraies sources de données dans l'environnement de développement et, en conséquence, dépendions de leur état. Il s'est avéré que nous avons indirectement vérifié ces sources dans les tests d'interface utilisateur. En conséquence, ils ont eu des tests instables qui sont tombés avec les sources et attendent une enquête sur les sources de données, ce qui n'a pas contribué à la vitesse de réussite des tests automatiques.

J'ai eu l'idée d'écrire ma propre maquette et de remplacer ainsi les sources d'Autotech. Mais à la fin, une solution plus simple a été trouvée - le MockServer prêt à l' emploi , le développement open source en Java.

Le principe de son travail:

• créer des attentes
• correspondre aux demandes entrantes,
• si une correspondance est trouvée - envoyez une réponse.

Un exemple de création d'une attente à l'aide d'un client java:

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" ) ); 

Comme vous pouvez le voir dans l'exemple, nous décrivons la demande que nous enverrons et la réponse que nous voulons recevoir. MockServer reçoit la demande, essaie de la comparer avec celles qui ont été créées et s'il y a des correspondances, il renvoie une réponse. Si la demande n'échoue pas, nous obtenons 404.

Pour MockServer, il existe des clients pour Java et JavaScript, une excellente documentation et des exemples d'utilisation. Il y a la possibilité de faire correspondre les demandes sur RegExp, la journalisation détaillée sur le serveur et tout un tas de puces. Pour nos besoins, c'était un candidat idéal. Le processus de lancement est décrit en détail sur le site, donc le raconter ici ne voit pas l'intérêt. Le seul moment, la dernière version était une fuite de mémoire, nous utilisons donc la version 5.2.3. Soyez prudent. Un autre inconvénient est que Mockserver n'a pas de prise en charge SOAP prête à l'emploi.

À l'heure actuelle, MockServer travaille avec nous depuis environ trois mois. En conséquence, la stabilité des tests, la vitesse de leur exécution et la capacité de recevoir des données sur un environnement de développement ont augmenté. Et en conséquence, il y a plus de possibilités de test.

Épilogue

Ces technologies sont les principales choses dont je voudrais parler dans cet article. Sinon, nous utilisons les outils de test habituels: tests d'API avec le paquet Kotlin + JUnit + RestAssured, Postman pour la commodité d'accéder à l'API. Dans cet article de revue, je n'ai pas parlé de notre approche des tests d'interface utilisateur. Nous utilisons MBT et graphwalker . Nous prévoyons de préparer un article avec des collègues à ce sujet.

Si vous avez des questions, posez-les dans les commentaires, j'essaierai d'y répondre. J'espère que cet article sera utile aux équipes de développement. (Soit dit en passant, alors qu'elle se préparait pour la sortie, un travail de développeur QA est apparu dans notre équipe, montre à ceux qui pourraient être intéressés).