Dans un article précédent, j'ai partagé mon expérience d'automatisation sur Robot Framework. Nous allons maintenant parler d'une approche légèrement différente pour tester l'API d'un projet sur Kotlin.
Profitant de la liberté de choisir la pile technologique et comptant sur le désir d'essayer quelque chose de nouveau «au combat», je me suis tourné vers Rest-Assured. Non sans quelques difficultés, mes collègues et moi avons lancé des tests, et suite au développement de l'approche, nous l'avons enregistrée dans la liste des tâches clés pour ce type de tâche.
(image utilisée comme parodie)Tout a commencé avec le fait qu'il y avait une demande d'automatisation des tests d'API sur l'un des nouveaux projets
du segment Ad-tech . Nous avons fait Campaign Manager, DMP et plusieurs intégrations avec des systèmes tiers. Et les testeurs avaient une tâche extrêmement simple: automatiser les tests de fumée pour une intégration plus poussée dans CI et une surveillance constante de l'état de cette API, car des systèmes tiers y sont liés et un fonctionnement correct est essentiel. Dans ce cas, la vérification de la logique métier n'était pas requise, car le service testé est essentiellement une interface proxy.
Pourquoi être rassuré?
Du point de vue de l'automatisation des tests, nous avons réussi à travailler dans une variété de domaines - UI, web, mobile, desktop, backend, REST API, SOAP.
Le projet précédent nous a donné beaucoup d'expérience sur Robot Framework, il serait donc plus logique de l'utiliser. La plupart de l'équipe de test le connaissent, et si un remplacement urgent est nécessaire, cela se fera rapidement et pratiquement sans douleur. Mais une décision différente a été prise.
Tout d'abord, le projet lui-même a été écrit en Kotlin et construit en utilisant Gradle. Dans le même temps, au stade de la conception, les autotests ont été décidés de ne pas attribuer de projet distinct. Comme indiqué dans les commentaires de l'article précédent, coller Java (Kotlin) et le cadre de robot est une grande douleur, il était donc inutile de se référer à RF. De plus, en repensant à travailler avec un robot, j'étais intéressé à essayer une approche différente. De plus, sur ce projet, nous avons pu choisir indépendamment une pile technologique - l'entreprise n'a pas fixé ses propres conditions.
À la recherche d'idées, je me suis tourné vers notre équipe de développement, ainsi que des collègues des tests, et le CTO
m'a conseillé de regarder Rest-Assured (
rest-assured.io ). Après avoir lu la documentation et les exemples de tests en open source, l'approche proposée par Rest-Assured m'a paru très attractive. Cela signifie recevoir une réponse du backend sous la forme de JSON, que nous désérialisons en bons vieux objets Java.
De plus, avec cette structure, vous pouvez travailler comme avec un objet normal. En conséquence, nous avons une approche orientée objet tout à fait normale pour valider la correspondance de la réponse de l'API avec la structure d'objet décrite. En prime, nous obtenons un test rapide et sans échec de la structure de réponse - si l'objet reçu en désérialisant la réponse de l'API diffère par le nombre de champs ou leurs noms, les tests chuteront même avant de vérifier les données avec une erreur de désérialisation. Nous comprendrons donc si nous devons réparer le backend ou mettre à jour les tests conformément aux nouvelles exigences de l'API. Dans notre cas, cela était important car, comme je l'ai mentionné ci-dessus, de nombreux sous-systèmes tiers sont liés à l'API.
Pour plus de précision, je note qu'environ le même test de sécurité peut être obtenu sur RF, mais d'une manière légèrement différente. Cependant, l'histoire d'aujourd'hui n'est pas à ce sujet. Personnellement, il était plus pratique et compréhensible pour moi d'entrer du côté de Rest-Assured avec une entité qui a certains champs et méthodes.
Test de plumes
Avant de commencer à utiliser la pile sur un vrai projet, j'ai décidé de l'essayer sur un petit service CRUD. Afin de ne pas pratiquer immédiatement ses propres erreurs, j'ai décidé de rechercher les meilleures pratiques dans cette pile et j'ai rapidement trouvé
un article de Philip Hauer , où il reflétait son expérience d'automatisation sur Rest-Assured. Après avoir étudié l'article, écrire une version de travail des tests de mon service n'a pas été difficile. Ils se sont avérés simples, faciles à lire et à comprendre.
À la bataille!
Le projet a démarré et lorsque les premières structures de réponse ont été décrites, la préparation de la documentation de test et la rédaction des autotests ont commencé. Pour comprendre la situation dans son ensemble, je vais donner une pile complète d'autotests:
- Java
- JUnit4 - exécution et paramétrage de scripts de test (annotation standard @Parametrize),
- Rest-Assured - construction et exécution de requêtes,
- AssertJ - validation des valeurs reçues,
- Allure - immeuble de rapport,
- Gradle - montage
- Jackson - désérialisation.
Lorsque les premiers tests ont été écrits, le problème du paramétrage correct est devenu apparent. Transmettre des valeurs simples de données et le résultat attendu semblait extrêmement inefficace et moche. Je n'ai pas eu le temps de résoudre ce problème avant les vacances, mais mes collègues, qui ont été impliqués pendant mon absence, ont tout réglé. Pour un paramétrage beau et facile à lire, ils ont décidé de créer une classe de base avec les fonctions d'ajout, de réception et de suppression de paramètres d'objet, dont toutes les classes dont les objets ont été utilisés pour appeler les méthodes API correspondantes ont été héritées.
Cela a permis littéralement à la volée de créer les données nécessaires et de les transmettre dans les paramètres de test.
Rest-Assured vous permet de désérialiser la réponse à la classe requise. La réponse résultante est décomposée en une structure précédemment connue à l'aide de Jackson. Les classes de désérialisation semblent aussi simples que possible - tous les champs attendus avec leurs types sont décrits.
De plus, un travail simple avec des objets et l'affirmation de champs spécifiques et de leurs valeurs se poursuit.
La chose la plus difficile et non évidente que j'ai rencontrée dans cette approche est l'incapacité de passer null à Rest-Assured comme l'un des paramètres (le résultat est une baisse de NullPointerException). Apparemment, c'est un problème connu, mais le développeur ne va pas corriger la situation, recommandant d'envoyer le champ vide ou de ne pas l'envoyer du tout. Nous étions déjà confrontés à ce problème au stade où la base du projet était prête et il ne restait plus qu'à ajouter des classes de test. Par conséquent, nous avons juste légèrement corrigé notre code.
En général, j'ai aimé l'approche. Il est curieux que, après un certain temps, il ait commencé à être appliqué sur le projet d'un autre client (mais pas de notre approvisionnement). Et nous avons placé la pile assemblée pour les API de test d'automatisation (JUnit + AssertJ + Rest-Assured) dans la catégorie des clés pour les projets Java / Kotlin. En Python, le tirer sera contre-intuitif, car il vaut mieux que les compétences de développement et de test se chevauchent.
Il convient également de noter que l'un des avantages de cette solution est son évolutivité et son adaptabilité à une logique complexe. Cela signifie qu'il convient le mieux aux projets sérieux où il est vraiment logique de décrire de grands objets, de nettoyer le code et l'architecture de bloc, lorsqu'il existe des éléments distincts chargés de préparer, de transmettre et de recevoir des données sous une forme lisible, ainsi que de vérifier ultérieurement la conformité des données certaines conditions. Dans les petits projets, tout cela n'a aucun sens à tirer.
Résumé
En environ un mois, nous avons pu automatiser environ 250 tests et fournir le niveau de couverture requis. Bien sûr, après la fin du processus d'automatisation, une présentation interne a été organisée pour tout le monde, afin que les employés aient une idée du travail effectué et puissent tirer profit de l'expérience acquise sur ce projet.
Auteur de l'article: Dmitry Masters
PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous à nos pages sur les
chaînes VK ,
FB ou
Telegram pour découvrir toutes nos publications et autres actualités Maxilect.