Accélérez les tests, ont-ils dit.
Et maintenant, près de six mois se sont déjà écoulés, lorsque nous avons réécrit nos anciens tests fonctionnels non coupés, longs et instables et sommes passés à des tests rapides indépendants des composants. Il est donc temps de partager :)
Pour ceux qui ne le savent pas, les
tests de composants sont des tests complètement isolés de l'environnement global et vous permettent de tester certains cas qu'un test unitaire ne pourrait pas couvrir.
Il y a six mois, la sortie d'une fonctionnalité prenait plus d'une heure, étant donné que le code était déjà entièrement testé depuis longtemps, mais la branche principale ne pouvait pas obtenir la construction verte en bambou, puis la question s'est posée: comment vivre?
En effet, dans ce cas, les tests de préjudice sont plus que bons, mais s'en débarrasser et les «marquer» pour les tests est loin d'être la meilleure option :) Ensuite, une petite micro-équipe a été organisée par le chef d'équipe:
- Timlida
- Développeur Backend
- Ingénieur QA
- Admin
Ayant rapidement coopéré, nous avons divisé nos tâches et l'une d'entre elles a été de mettre en place un environnement pour l'écriture des tests de composants. Et donc mon voyage a commencé.
Au début du développement, nous avions plus de 140 tests fonctionnels qui ont été exécutés dans plusieurs threads dans différents environnements (Frontend, Mobile, Backend) et ils ont pris environ 5-7 minutes; ont également souvent dû les redémarrer afin de réaliser une construction verte. Et ces tests ne sont plus tombés à cause du nouveau code écrit, mais à cause de problèmes dans l'environnement, c'est-à-dire quelque part où l'API n'a pas répondu, quelque part où le microservice de test est tombé, etc. Cela a arrêté le travail de tout le département, car les assemblages ont commencé presque toutes les 5 à 10 minutes: quelqu'un a remonté, quelqu'un a poussé un nouveau code ...
Après la première moitié de la semaine, nous sommes arrivés à la conclusion que nous allons «mouiller» notre API et nos services tiers, ce qui nous donnerait un environnement de test complètement isolé. Mais la question s'est posée: écrire quelque chose de leur propre chef ou ... Alors, sur ce «ou» tout s'est terminé - par une courte recherche, en chemin j'ai rencontré - un petit temps de fonctionnement sous la forme du serveur Mock «http-api-mock».
http-api-mock est un serveur factice léger et sans installation écrit en Go avec une bonne documentation.
Après des centaines de tentatives de lancement, ainsi que de plonger généralement dans le sujet de mok, j'ai quand même réussi à réécrire 1 test fonctionnel, qui a créé une nouvelle annonce sur le site et, après avoir passé tous les cercles de l'enfer, était convaincu que le titre sur la page correspond au titre dans le corps de l'objet.
Imaginez gagné! Le test réécrit s'est avéré 3 fois plus rapide que le précédent, car ici nous n'avons pas vérifié la création, la modération, mais avons immédiatement renvoyé l'objet publicitaire souhaité du Mock et avons gagné. Cette petite victoire est devenue une bonne incitation pour le développement de ce sujet, ainsi, après une autre semaine, nous avons eu une nouvelle suite en codeception appelée "composant", qui avait déjà une classe d'aide de base pour travailler avec notre serveur Mock et a été lancée à ce moment-là moi dans le bac à sable.
La classe d'assistance de base peut créer une annonce sous la forme d'un fichier json dans le répertoire config de notre faux serveur, donner l'annonce souhaitée par id, etc. Presque une API.
Le reste de la magie nous attendait plus loin - maintenant il ne restait plus qu'à mettre en place le plan de montage en bambou. Pour que nos tests passent maintenant par notre CI&CD.
L'administrateur nous a aidés à cela - avec la configuration du lancement de tous ces tests dans Docker, ce qui nous a permis d'augmenter notre conteneur avec le serveur Mock pour chaque build et d'exécuter nos tests dans un environnement complètement isolé sans déployer notre code sur un backend de test, qui ne pouvait pas non plus N'accélérez pas nos tests.
Pour travailler toute cette magie, nous avons dû ajouter de nouveaux fichiers de configuration avec une nouvelle adresse API et des services externes, ainsi que générer une copie de la base de données mysql, et également créer une nouvelle tâche dans le plan de build avec le lancement de notre faux serveur.
Maintenant, pour notre code, il existe une toute nouvelle API qui, indépendamment de tout problème environnemental, nous donnera ce que nous voulons.
Le temps a passé, les tests ont été réécrits et 140 tests fonctionnels se sont transformés en 103 tests de composants, qui s'exécutent en parallèle en ~ 30 secondes.
Des pros
Très agile . Du fait qu'ils sont totalement indépendants de l'environnement de test, ils n'ont pas à aller loin pour les données.
Stable . Les tests n'ont pas à vous soucier de savoir si notre API ou tout autre service est tombé là-bas, nous sommes donc toujours sûrs que le résultat nous parviendra.
Facile à écrire . En fait, dans le processus de réécriture, beaucoup a été décidé en copiant le code de l'ancien test fonctionnel vers le nouveau test de composant et en préparant des points de terminaison pour celui-ci dans le serveur Mock.
Des inconvénients
Support . Désormais, chaque développeur qui a apporté des modifications à la réponse retournée pour un point de terminaison spécifique dans l'API se rend également dans le référentiel avec des configurations pour le serveur simulé et y corrige la réponse.
Un tas de fichiers . Ils ont décidé de stocker les données avec des configurations sous forme de fichiers, c'est-à-dire que chaque réponse pour le point final se trouve dans un fichier et peut être perdue quelque part.
Résultats:
Les testsC'était: 140+ tests fonctionnels = 5-7 minutes.
Maintenant: 103 tests de composants = ~ 30 secondes.
Construire la stabilitéC'était: Chaque troisième assemblée est tombée en raison de problèmes.
Il est devenu: ne tombe que lorsque le développeur a rompu la logique d'une méthode.
Dans les plans futurs, nous devons réécrire les tests d'acceptation (GUI) - également les exécuter à l'intérieur du conteneur et les isoler du reste de l'environnement.