Des tests automatiques sur les projets sont nécessaires. Mais, comme on dit, l'automatisation du goût et de la couleur peut être différente. Nous sommes arrivés à un projet où il y avait déjà des autotests et avons pu améliorer la couverture et accélérer le passage des tests sans révolution fondamentale. Sous le chat sur la façon dont nous l'avons fait.
Quelques mots sur le projet
Bien que nous ne puissions pas divulguer les détails du projet en raison de la NDA, en termes généraux, la tâche était la suivante. Nous avons rejoint le développement du service API fintech, qui a interagi avec la base de données, renvoyant les objets financiers nécessaires (prix, tarifs, etc.). Notre tâche consistait à tester les clients mobiles pour ce service - à la fois les applications Web et les applications mobiles natives.
L'automatisation des tests sur ce projet s'est développée progressivement, parallèlement à la complexité du service. C'est probablement la durée pendant laquelle les tests de bout en bout sont apparus en même temps, ce que nous avons trouvé sur le projet. La plupart d'entre eux ne fonctionnaient pas à ce moment-là, car le service avait changé et il n'y avait personne pour prendre en charge les tests - le seul ingénieur en automatisation a quitté le projet bien avant notre arrivée.
Même les tests qui semblent correspondre à la fonctionnalité sont parfois tombés en raison de la confusion avec les versions ou de l'inaccessibilité des ressources externes. Pour les tests, une infrastructure distincte a été utilisée - des bancs de test, où les versions nécessaires ont été déployées pour des expériences. Différents groupes de travail y ont eu accès et n'ont pas toujours agi de concert. À la suite des actions d'un groupe, une API importante utilisée par notre service pourrait tomber, à cause de laquelle même un test de travail a cessé de passer. C'est-à-dire le test n'a plus montré la facilité de service du service lui-même, mais plutôt lié à l'infrastructure de test dans son ensemble.
Comment nous sommes arrivés au chaos
Il semblerait que dans cette situation, il est nécessaire d'abandonner toutes les anciennes réalisations et de reconstruire les tests. Mais nous avons agi plus «humainement». La structure de test elle-même a été préservée, en se concentrant sur la résolution de problèmes spécifiques - passage lent des tests, leur instabilité et couverture insuffisante des cas de test. Pour chacun d'eux, il y avait une solution.
Refactoring
Tout d'abord, nous avons partiellement retravaillé le code des anciens tests, en nous appuyant sur des modèles de conception plus modernes.
Une partie du code hérité a dû être supprimée - elle était trop difficile à maintenir. Dans une autre partie, nous avons détecté toutes les faiblesses - nous avons remplacé le sommeil par défaut par des serveurs normaux, fait des préparatifs pour tous les tests dans la configuration globale via les annotations des lanceurs de tests, etc. De nombreuses petites étapes ont réduit la réussite moyenne du test de bout en bout de 3-4 à 1-2 minutes.
Approche atomique
Pour accélérer la création de nouveaux tests et simplifier la prise en charge des anciens, nous sommes passés de cas complexes de bout en bout.
Personnellement, je n'ai rien contre les tests de bout en bout, cependant, dans le cas où vous devez vérifier un écran spécifique (ou même une partie des informations), parcourir toutes les étapes, en commençant par l'autorisation de l'utilisateur, est trop cher. Imaginez que nous testons une boutique en ligne et que nous avons seulement besoin de vérifier le chèque qui sera envoyé à l'acheteur après l'achat d'un certain produit. Au lieu d'aller chercher un seul écran dans le système, nous irions par identifiant et mot de passe, sélectionner le produit, confirmer l'achat, etc. - effectuerait de nombreuses étapes qui ne sont pas liées à une tâche de test spécifique. Mais chaque étape prend du temps. Même avec toute l'optimisation effectuée, le lancement du test de bout en bout a pris jusqu'à 2 minutes, tandis que la vérification d'un écran spécifique n'a pris que 10 secondes. Par conséquent, là où c'était possible, nous sommes passés à de tels contrôles «atomiques», en nous référant uniquement à l'écran qui nous intéresse dans le cadre du cas de test.
En cours de route, juste pour la comparaison d'écran, nous avons implémenté des tests de clichés, ce qui vous permet de vérifier la part du lion de l'interface utilisateur. Ayant des tests et du code d'application dans un référentiel, nous pouvons utiliser les méthodes de cette application dans des tests, c'est-à-dire soulevez tous les écrans qui sont nécessaires dans ce processus. Nous pouvons donc trouver des erreurs dans la comparaison des captures d'écran de test avec celles de référence.
Nous avons maintenant environ 300 tests d'instantanés, et leur nombre augmente progressivement, car cette approche peut réduire considérablement le temps nécessaire pour vérifier la version finale avant de l'envoyer en production. Cet ensemble de tests démarre automatiquement lorsque la demande d'extraction est ouverte et s'exécute en 40 minutes - afin que les développeurs reçoivent rapidement des commentaires sur les problèmes de la branche actuelle.
Bien sûr, un certain nombre de tests de bout en bout ont été conservés. Vous ne pouvez pas vous en passer là où vous devez vérifier des scénarios de grande entreprise, mais il est logique de les exécuter lorsque tous les détails ont déjà été vérifiés.
Moqueur
Pour exclure l'influence d'un banc de test instable sur le résultat du lancement de nos tests, nous avons lancé un faux serveur. À propos des décisions que nous avons ensuite envisagées et pourquoi avoir choisi Okhttpmockwebserver,
j'ai déjà écrit sur Habré .
En conséquence, la part des cas de chute épisodique due à des causes externes des tests a diminué de manière significative.
Kotlin DSL
En parallèle, nous avons rendu les tests plus lisibles.
Les personnes impliquées dans les tests d'interface utilisateur savent à quel point il est difficile de trouver la vérité parmi un groupe de localisateurs dans la longue «nappe» du test (en particulier au stade où il s'agissait encore de tests de bout en bout). Il est facile de s'y retrouver lorsque vous travaillez sur un projet depuis deux ans et même au milieu de la nuit, vous pouvez vous souvenir de quoi. Mais si vous venez de venir, passer à ce qui se passe est une grande tâche distincte. Afin que les nouvelles personnes n'aient pas à y faire face à chaque fois, nous avons décidé de passer au Kotlin DSL. Il est implémenté assez simplement et a une structure simple et compréhensible. Si auparavant, les tests consistaient en un ensemble d'appels de bas niveau identiques - clics, saisie de texte, parchemins, maintenant tout cela s'est transformé en quelque chose de plus «professionnel» - quelque chose comme une approche BDD. Tout est visible et compréhensible.
À mon avis, cela nous a fait une certaine réserve pour l'avenir. Ce projet a déjà rencontré une fois le départ d'un seul ingénieur en automatisation. Pour les tests, cela ne s'est pas terminé de la meilleure façon - ils ont simplement cessé de les soutenir, car le seuil d'entrée s'est avéré trop élevé. La compréhension d'un tel code sec a demandé beaucoup de temps et une certaine qualification. Nous avons repensé les tests de telle manière qu'il sera possible à tout moment de transférer rapidement des personnes d'autres projets ou des tests manuels vers l'automatisation. Presque n'importe qui peut écrire les tests les plus simples sur Kotlin DSL. Ainsi, l'automatisation peut quitter l'implémentation de bas niveau et écrire rapidement de nouveaux tests simples pour connecter les personnes de l'équipe fonctionnelle. Ils ont une connaissance suffisante de la logique métier et le projet bénéficiera du fait qu'ils seront davantage impliqués dans le processus d'écriture des autotests. Kotlin DSL vous permet de décrire les cas de test exactement comme ils aimeraient voir toutes les vérifications, laissant l'implémentation de bas niveau des méthodes en dehors de la portée de leur travail.
En général, tout cela a permis d'augmenter plus rapidement la couverture des autotests. Si auparavant, il a fallu 16 à 20 heures pour mettre en œuvre la nouvelle suite de tests, puis avec la nouvelle approche, en fonction de la complexité des tests, cela prend de 4 à 12 heures (et les coûts de main-d'œuvre pour le support ont été réduits de 16-24 à 8-12 heures en semaine).
Auteur de l'article: Ruslan Abdulin.
PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous à nos pages sur
VK ,
FB ,
Instagram ou la
chaîne Telegram pour en savoir plus sur toutes nos publications et autres actualités Maxilect.
PPS Aidez-nous à rendre nos articles de blog plus intéressants:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .