Structure pour les tests de pagemodel sélénium

Question

Je me suis récemment plongé dans l'utilisation de modèles de sélénium et d'objets de page pour tester i C# (couplé avec SpecFlow).

Cependant, je suis un peu incertain sur la structure des modèles d'objet de page dans un de mes cas.

À titre d'exemple, j'ai un formulaire d'inscription, qui couvre plusieurs pages (remplir les détails, appuyez sur suivant, remplir plus de détails, appuyez sur suivant, etc.)

Serait-il les meilleures pratiques pour créer une page modèle d'objet pour chaque page dans le flux, ou de rassembler tous dans un modèle d'objet d'une page?

Pour pimenter les choses, dans certains scénarios, les éléments de formulaire pourraient se déplacer vers d'autres pages dans le flux (selon la configuration du client final)

Answer 1

objets Page est un modèle de conception bien connue, largement acceptée par les ingénieurs d'automatisation , pour créer un fichier de classe séparé pour chaque page de l'application afin de regrouper tous les éléments en tant que propriétés et leurs comportements/fonctionnalités métier en tant que méthodes de la classe. Mais ce n'est peut-être pas toujours une bonne idée, surtout quand la page a plus/différents ensembles d'éléments/éléments complexes comme un widget grille/calendrier/une table HTML, etc.

Lorsque vous essayez d'incorporer tous les éléments d'un page dans une classe de page unique, il devient trop grand pour lire, maintenir etc. La classe peut contenir trop de responsabilités à gérer. Il peut être restructuré et divisé en classes plus petites.

Je m'attendrais à ce que mes objets de page satisfassent le responsable unique. En faisant cela, vous finirez avec plus de classements pour une page - mais vos tests seront si lisibles, fiables et robustes.

Vous pouvez voir les exemples ici en Java. Mais je suis sûr que vous aurez l'idée.

http://www.testautomationguru.com/arquillian-graphene-page-fragments/