Il y a un peu plus d'un an, j'ai essayé le Robot Framework pour la première fois. Lors de ma participation à un projet de grande envergure, j'ai expérimenté deux approches différentes pour tester l'automatisation avec cet outil: écrire des tests sur un DSL Robot Framework pur et travailler en collaboration avec Python. Si le premier chemin a un seuil d'entrée bas, alors le second, à mon avis, est plus pratique du point de vue du soutien de grands projets. Bien qu'il n'y ait pas de différence fondamentale entre les approches. D'une manière ou d'une autre, tout se résume à trouver des bibliothèques.
Cependant, il vaut la peine de parler des caractéristiques des approches.
Qui est Robot et avec quoi mange-t-il
Il vaut probablement la peine de commencer par l'introduction de cet outil puissant.
Robot Framework est un cadre pour les tests basés sur des mots clés. Il est utilisé pour automatiser les tests d'acceptation et ATDD (approche de développement à travers les tests d'acceptation). Ce système possède une syntaxe de données de test facile à utiliser et vous permet d'automatiser les tests à l'aide de mots clés. De plus, le Robot Framework possède d'excellentes bibliothèques intégrées et tierces qui vous permettent de démarrer rapidement et d'intégrer l'automatisation dans les processus de travail sans inventer vos propres vélos - le seuil d'entrée très bas que j'ai mentionné ci-dessus.
La structure de base de Robot Framework est implémentée à l'aide de Python et fonctionne également sur Jython (JVM) et IronPython (.NET).
Des exemples d'utilisation ainsi qu'une documentation complète sur le framework et les bibliothèques internes sont disponibles sur le site officiel du projet:
http://robotframework.org/ .
Mes premiers pas. Première approche
Pour la première fois, je suis tombé sur le Robot Framework il y a un an, après avoir changé d'emploi. Avant cela, je n'avais automatisé qu'en Java et C #.
En choisissant moi-même les outils avec lesquels je dois gérer les tests existants, j'ai interrogé de nouveaux collègues sur leurs préférences. Ils n'étaient pas d'accord sur le meilleur IDE pour travailler avec le Framework Robot. Les plugins pour divers éditeurs de texte et IDE, tels que PyCharm, permettent principalement de travailler avec Robot Framework. Et les recommandations que j'ai recueillies étaient divisées 50/50 entre Atom et PyCharm. Bien sûr, il y a RIDE, mais ce n'est pas une panacée. A cette époque (il y a un an), je n'ai pas trouvé de documentation normale dessus, et dans celle que j'ai trouvée, je n'ai vu aucun gros avantage pour ma tâche. Par conséquent, pour commencer, j'ai décidé d'essayer Atom avec des plugins. En clonant le référentiel, j'ai commencé à étudier lentement ce qui se passait dans nos tests et dans le Robot Framework lui-même.
J'ai été connecté au projet pour pratiquement tout. Un tas de Jython + Robot Framework y travaillait déjà, une énorme base de code (écrite sur le DSL Robot Framework lui-même) a été assemblée à partir de plus de 1000 tests et de plusieurs milliers de lignes de code de bibliothèques auxiliaires en Java.
Si je comprends bien, lorsque le projet a commencé, c'est-à-dire avant même d'arriver au département, ce sont principalement des spécialistes Java qui y ont travaillé, et le produit testé lui-même était en Java, donc lors du choix d'une approche, nous nous sommes concentrés sur les ressources disponibles. En général, le calcul était quelque chose comme ceci: après avoir résolu certains problèmes liés à l'intégration de Robot Framework et Java (principalement en raison du fait que Java est un langage compilé, mais le même Python et les mêmes tests dans le bundle Python + RF sont interprétés), puis il est facile d'attirer des experts tiers qui ne connaissent que DSL Robot Framework et d'écrire tranquillement des tests sur des mots clés. Certes, les collègues ont dû consacrer beaucoup d'efforts à la création de bibliothèques en Java, par conséquent, sans conditions du client, ils ne recommanderaient pas un tel chemin.
Après avoir fait un peu de refactoring, dans le cadre de ma première tâche, j'ai d'abord effectué les tests. Depuis que le bundle Jython + RF a été utilisé, tout a été collecté par maven, et les fichiers du robot ont été simplement copiés dans le répertoire cible pour une exécution ultérieure.
Les tests ont été exécutés par des scripts (fichiers .bat ou .sh) qui ont pris le chemin vers un scénario de test distinct (un fichier .robot distinct) ou un plan de test (un fichier avec une liste de chemins relatifs aux scénarios de test).
La refactorisation a affecté un grand nombre de tests, donc la première exécution a duré environ 15 minutes. Une fois terminée, il est temps de jeter un œil aux rapports fournis par le Robot Framework.
Le rapport standard (dans la capture d'écran ci-dessus) se compose des fichiers report.html et log.html:
- le rapport contient un résumé général de la dernière exécution, où vous pouvez voir les résultats de surface de tous les tests (réussi ou échoué);
- dans le fichier journal, vous pouvez voir des informations plus détaillées - l'exécution de chaque test étape par étape. Là, vous pouvez afficher tout ce dont vous avez besoin pour déboguer les tests.
Honnêtement, dès le premier coup d'œil au rapport Robot Framework, l'œil commence à trembler un peu: une énorme quantité d'informations est affichée et il faut un certain temps pour comprendre la structure de bout en bout des tests et développer les compétences nécessaires pour lire un tel journal. Mais cette affaire n'est pas si délicate. Dans quelques mois, je pourrais citer The Matrix: «Votre cerveau fait la traduction lui-même. Je ne vois même pas le code. Je vois une blonde, une brune et une rousse. » J'ai donc - vu toutes les informations nécessaires dans un fichier sans outils supplémentaires.
Le plus est que la sortie peut être contrôlée: il existe différents niveaux de journalisation qui déterminent quelles informations seront affichées et lesquelles ne le seront pas. Le niveau peut être ajusté même pour chaque ligne individuellement grâce à la méthode de bibliothèque intégrée. Dans le même temps, connaître l'ordre des appels à l'intérieur des bibliothèques de test et auxiliaires n'est pas superflu - il est plus facile de saisir le moment de l'erreur.
En utilisant le DSL Robot Framework comme notre outil principal, nous avons travaillé pendant environ six mois. Pendant ce temps, je suis passé des préférences personnelles d'Atom à VSCode, mais cela n'a pas changé l'essence de l'approche.
Cependant, le projet se développait. Au cours de l'itération finale, la bibliothèque auxiliaire pour travailler avec la base de données totalisait 6 700 lignes de code sur un pur Robot Framework. Avec une telle échelle de la base de code, il est devenu difficile à maintenir - refactoriser les ressources requises qui n'étaient pas allouées.
Le dernier mot dans l'application de la première approche appartenait aux entreprises. Le client de notre projet a également travaillé avec d'autres équipes sur des tâches connexes. Dans l'une des pistes parallèles, il a vu, de son point de vue, une option plus efficace et illustrative pour l'utilisation de Robot Framework, qui a commencé à être mise en œuvre spécifiquement pour la gestion.
Deuxième approche
La deuxième approche a été le développement de tests en Python en collaboration avec le Robot Framework. Au lieu de tout créer sur la syntaxe DSL Robot Framework, nous avons commencé à écrire des bibliothèques d'assistance et d'autres interactions de bas niveau avec le produit de test en Python. Et le Robot Framework, en fait, est devenu juste un coureur.
Étant donné que Python est un langage de haut niveau pur, pas DSL, il existe plus d'options structurantes, il est plus facile de tout comprendre. Au minimum, vous pouvez utiliser l'IDE Python pour vous aider à trouver les mêmes méthodes (ils font la même chose, mais sont appelés différemment) ou même écrire un morceau de code pour vous. Certaines données peuvent être enveloppées dans des générateurs, accrocher des décorateurs sur des fonctions, etc. Dans ce contexte, les outils de la première approche (pure Robot Framework) semblent plutôt durs - en fait, c'était le Bloc-notes avec mise en évidence de la syntaxe. Aucun setters ou getters qu'IntelliJ écrit pour vous. J'étais donc heureux de revenir à une langue de niveau supérieur. Travailler avec cette approche ressemble plus à un développement normal. Certes, il y a une mouche dans la pommade. Sans danse supplémentaire, il est impossible de comprendre ce qui est tombé à l'intérieur de Python, appelé de RF.
Lentement, les premiers tests et bibliothèques auxiliaires pour notre sous-système ont commencé à être écrits. Pendant le temps que j'ai pu travailler avec une nouvelle approche, j'ai senti qu'avec un autre outil il y avait vraiment plus d'opportunités. Mais en fait, la rédaction des tests n'a pas beaucoup changé. Dans ce projet particulier, à l'intérieur du code Python, les méthodes de bibliothèque intégrées de Robot Framework étaient toujours appelées. Cela était dû aux exigences particulières du client pour le développement de tests. Nous avons simplement séparé la partie exécutable de l'algorithme du scénario de test.
Quel est le meilleur?
Personnellement, j'aime la deuxième approche. Cependant, en choisissant le chemin de votre projet, cela vaut la peine de commencer par la tâche - qui écrit les tests et comment.
Comme je l'ai dit ci-dessus, Python (la deuxième approche) offre plus de possibilités, mais dans ce cas, des personnes qui connaissent ce langage sont nécessaires sur le projet. Le Robot Framework lui-même (et la première approche) est moins exigeant - vous pouvez l'approcher en lisant la documentation officielle sur sa DSL. Après avoir étudié le guide de l'utilisateur, vous pouvez créer des tests - ils auront l'air assez propres.
En conséquence, le cadre de robot et la façon dont nous l'avons utilisé au départ conviennent mieux aux testeurs manuels d'hier sans aucune expérience de programmation explicite dans des langages de haut niveau. Même une personne peu impliquée dans la programmation peut écrire un test, simplement en appelant les mots-clés nécessaires.
Cependant, si vous souhaitez conserver la partie exécutable séparée, en suivant l'exemple de notre projet, et en même temps refactoriser le code dans des IDE conviviaux, la deuxième approche est pour vous.
Auteur de l'article: Dmitry Masters
PS: Nous publions nos articles sur plusieurs sites Runet. Abonnez-vous à nos pages sur les
chaînes VK ,
FB ou
Telegram pour découvrir toutes nos publications et autres actualités Maxilect.