Get best of the week

4 meilleurs modèles de conception pour les tests automatisés (et 86 autres)

Bonjour à tous. En prévision du début du cours, «Python QA Engineer» a préparé une traduction d'un autre matériel intéressant.



La plupart du succès de vos projets d'automatisation réside dans la réutilisation de modèles de test bien connus, qui, comme cela a déjà été prouvé, contribuent à accroître la fiabilité des scénarios d'automatisation.

Un modèle de conception de tests automatisés est une solution simple qui prouve son efficacité au jour le jour dans le monde. Ces modèles sont également considérés comme les meilleures pratiques pour tout projet construit avec une programmation orientée objet.

Pourquoi les modèles de conception sont-ils si importants pour les tests automatisés?

Tenez pour acquis que vos demandes évolueront avec le temps.
Et puisque vous savez que le changement se produira d'une manière ou d'une autre, vous devez utiliser les meilleures pratiques et les modèles de conception dès le début. Ils rendront vos tests réutilisables et plus faciles à maintenir.

Voici quelques modèles de conception de tests automatisés courants que de nombreuses équipes utilisent pour créer une automatisation de test robuste et améliorer l'ensemble de la logique de test.

Objets de page



Un exemple de Page Object par Nikolay Advolodkin de Automation Guild 2017

L'une des stratégies les plus utilisées pour tester l'automatisation consiste à modéliser le comportement de votre application.
Pour ce faire, vous pouvez utiliser des objets de page simples qui simulent les logiciels que vous testez.
Par exemple, vous pouvez écrire un objet de page pour une page de connexion ou une page d'accueil. Cette approche reflète correctement le principe de la responsabilité partagée.

Si quelque chose change, par exemple, l'ID de l'élément, vous devrez modifier un seul endroit dans le code, et tous les tests utilisant cet objet de page recevront automatiquement cette modification sans action inutile. Le code de test ne doit être mis à jour qu'en un seul endroit. Cette approche permet également de réduire la duplication de code.

Les objets de page masquent également les détails techniques de HTML et CSS derrière des méthodes avec des noms simples et clairs.
L'attention à la dénomination de vos méthodes a l'avantage supplémentaire de contribuer à créer une interface de programmation d'application (API) agréable et lisible qu'un programmeur moins techniquement averti peut rapidement utiliser.

Ce modèle suit également la pratique populaire de développement de logiciels DRY (Don't Repeat Yourself, Don't Repeat It).
Fondamentalement, le principe DRY signifie que pour chaque partie de la logique, un morceau de code et pas plus devrait être responsable. La duplication dans le code le rend difficile à maintenir; moins vous écrivez de code, mieux c'est, car plus de code pris en charge signifie plus de chances qu'une erreur se glisse dans votre infrastructure de test.

Ce modèle de conception de logiciel peut à lui seul résoudre facilement la majeure partie de vos problèmes de test, mais ce n'est pas non plus une panacée. Cependant, cela vous permettra de faire un grand pas en avant, rendant vos tests fonctionnels automatisés plus stables.
Certains testeurs soutiennent que le modèle d'objet de page viole souvent le principe selon lequel une classe ne devrait avoir qu'une seule raison de changer.

Pour éviter cela, beaucoup se tournent vers le script, qui a été décrit pour la première fois par Anthony Marcano ( @AntonyMarcano) avec la participation d'Andy Palmer ( @AndyPalmer), Jan Molak ( @JanMolak) et d'autres.

Modèle de scénario


Les objets de page sont un bon moyen de commencer à rendre vos tests maintenables, mais si vous ne faites pas attention, ils peuvent toujours devenir incontrôlables avec le temps.
Le modèle de scénario (autrefois appelé modèle Journey) est une application des principes de conception SOLIDE pour les tests d'acceptation automatisés et aide les équipes à résoudre ces problèmes. C'est, en substance, ce qui a été le résultat d'une refactorisation impitoyable des objets de page en utilisant les principes de conception SOLID.

Le modèle de scénario prend des objets de page et les divise en très petits morceaux. Certains testeurs affirment que cela a rendu leurs tests plus faciles à maintenir et fiables.
Un autre avantage important est qu'il rend les scripts de test plus lisibles.

La première fois que j'ai entendu parler du modèle de scénario dans la session Automation Guild en 2017, c'était de John Smart (le @Wakeleo)créateur de l'un de mes cadres d'automatisation de test préférés, Serenity .
Screenplay utilise l'idée d'acteurs, de tâches et d'objectifs pour décrire officiellement les tests, refusant les termes d'interaction avec le système. Scénario, vous décrivez les tests en termes d'un acteur qui a des objectifs.

Voici un exemple:


Un exemple de la mise en œuvre du modèle de scénario de l'Automation Guild Session 2017 par John Smart

À première vue, il peut sembler que l'utilisation de ce modèle est beaucoup plus difficile que les mêmes objets de page, mais John a mentionné que l'utilisation de cette approche économise beaucoup de temps aux équipes avec lesquelles il a travaillé en réduisant les coûts de maintenance et de support.

Ports et adaptateurs


L'architecture des ports et des adaptateurs vise à garantir que vous utilisez le principe de la responsabilité unique , c'est-à-dire qu'un objet spécifique doit faire une chose et avoir une seule raison pour le changement.
Lorsque vous l'utilisez dans l'automatisation, assurez-vous de séparer le code du cas de test de tout le reste afin de pouvoir échanger des composants lents et des simulateurs rapides, vous permettant ainsi d'exécuter le test et l'application testée en un seul processus.

Débarrassez-vous des réseaux et des E / S afin que rien ne ralentisse la suite de tests. Bien sûr, ce n'est pas facile à faire, mais plus vous vous efforcerez de le faire lors de la création de l'automatisation de l'interface utilisateur, mieux ce sera pour vous.

J'ai appris ce modèle lors d'une interview avec le créateur de Cucumber Aslak Hellesoy ( @aslak_hellesoy)il l'a décrit comme une stratégie pour obtenir un retour rapide des tests de bout en bout de Cucumber.

Aslak a également recommandé une ressource appelée Todo-subsecond , que j'ai ajoutée à mon article Top Resource for Test Automation Engineers : cette petite application avec des tests d'acceptation de pile complète qui peuvent être effectués en millisecondes est conçue pour illustrer les méthodes de base pour y parvenir sur n'importe quel système. Après avoir terminé une série d'exercices, vous apprendrez une façon spéciale de mettre en œuvre développement axé sur le comportement.

Présentateur d'abord


Presenter First est une modification du modèle-vue-contrôleur (MVC) pour organiser le code et le développement afin de créer un logiciel entièrement testé en utilisant une approche de développement pilotée par les tests (TDD).
J'ai d'abord appris ce modèle lors d'une interview avec Sab Rose (@SebRose), l'un des contributeurs au projet Cucumber et auteur de Cucumber for Java.
Il a dit que si vous dessinez le modèle MVC sous forme de blocs et de flèches, vous verrez que la vue, qui est votre interface utilisateur, a des connexions clairement définies avec le modèle et le contrôleur. Si au moment de l'exécution, vous pouvez les remplacer par des modèles et des contrôleurs que votre test crée et contrôle, il n'y a aucune raison pour que vous ne puissiez pas vérifier que l'interface utilisateur ne se comporte pas comme vous le souhaitez.

Vous pouvez également personnaliser votre modèle et votre contrôleur afin qu'ils simulent toutes sortes de comportements étranges, par exemple une panne de réseau.

86 autres modèles de tests automatisés


J'ai écrit cet article il y a plusieurs mois, mais je ne l'ai jamais publié.
J'étais confiante sur ma liste jusqu'à ce que je parle avec Seretta Gamba , auteur du nouveau livre A Journey through Test Automation Patterns , où elle et sa co-auteur Dorothy Graham parlent de 86 modèles!

Ils décomposent les modèles en quatre catégories distinctes: les modèles de processus, les modèles de contrôle, les modèles de conception et les modèles d'exécution.
Ceux que j'ai décrits se réfèrent aux modèles de conception, mais il existe de nombreux autres modèles qui résolvent les problèmes non seulement avec le code.

Par exemple, il existe des modèles liés à une culture d'entreprise et à des modèles de gouvernance médiocres qui, selon mon expérience, ont tendance à annuler tous les efforts d'automatisation des tests.
Pour une liste complète, consultez le wiki du modèle de conception ou commandez un livre sur Amazon.

En savoir plus sur le cours.

More articles:


All Articles