Automatisation de l'interface graphique BDD

Architecture BDD

BDD automation se compose généralement de quelques couches:

1. Les étapes du langage naturel
2. Le câblage qui lie les étapes à leur définition
3. Les définitions d'étape, qui accèdent généralement aux objets de page
4. Objets de page, qui fournissent toutes les capacités d'une page ou d'un widget
5. Automatisation sur le code réel en cours d'exercice, souvent via l'interface graphique.

Le câblage entre les étapes du langage naturel et les définitions d'étape sont normalement effectuées par l'outil BDD (Concombre).

L'automatisation se fait normalement à l'aide de l'outil d'automatisation (Sélénium). Parfois, les gens ignorent l'interface graphique, ciblant peut-être une API ou la couche MVC à la place. Cela dépend de la complexité de la fonctionnalité de votre page Web. En cas de doute, donner le Sélénium essayer. J'ai écrit des frameworks d'automatisation pour les applications de bureau; le principe est le même quel que soit.

Garder maintenable

Pour faciliter les étapes pour maintenir et changer, gardez les étapes à un niveau assez élevé. Ceci est souvent appelé "déclaratif" par opposition à "impératif". Par exemple, ceci est trop détaillé:

When Fred provides his receipt
And his receipt is scanned
And the cashier clicks "Refund to original card"
And the card is inserted...

Pensez à ce que l'utilisateur essaie de réaliser:

When Fred gets a refund to his original card

Généralement, un scénario aura quelques Givens ou Thens, mais généralement un seul When (sauf si vous avez quelque chose comme l'interaction des utilisateurs ou le temps qui passe, où les deux événements sont nécessaires pour illustrer le comportement).

Vos objets de page dans ce scénario pourrait bien être un " RefundPageObject "ou peut-être, si c'est trop grand, un"RefundToCardPageObject". Ce modèle permet à plusieurs étapes de scénario d'accéder aux mêmes capacités sans duplication, ce qui signifie que si la façon dont les capacités sont exercées change, vous n'avez besoin de les modifier qu'à un seul endroit.

Différents objets de page peuvent également être utilisés pour différents systèmes.

Mise en route

Si vous attaquez ceci pour la première fois, commencez par obtenir un scénario vide qui s'exécute et passe sans rien faire (rendre les étapes vides). Lorsque vous avez fait cela, vous aurez réussi à câbler le concombre.

Écrivez le code de production qui ferait fonctionner le scénario. (C'est l'inverse de la façon dont vous le feriez normalement; normalement, vous écririez le code du scénario en premier. J'ai trouvé que c'est un bon moyen de commencer.)

Lorsque vous pouvez exécuter votre scénario manuellement, ajoutez l'automatisation directement à les étapes (vous n'avez qu'un scénario à ce stade). Utilisez votre package d'assertion préféré (JUnit) pour obtenir le résultat que vous recherchez. Vous aurez probablement besoin de changer votre code afin de pouvoir automatiser facilement, par exemple: en donnant des ID de test pertinents aux éléments de votre page Web.

Une fois que vous avez un scénario en cours d'exécution, essayez d'écrire d'abord les scénarios suivants; cela vous aide à réfléchir à votre conception et à la testabilité de ce que vous êtes sur le point de faire. Lorsque vous commencez à ajouter plus de scénarios, commencez également à extraire cette automatisation dans des objets de page.

Une fois que vous avez quelques scénarios, réfléchissez à la façon dont vous voudrez peut-être aborder différents systèmes. Évitez d'utiliser beaucoup d'instructions "si" si vous le pouvez; celles-ci sont difficiles à maintenir. L'injection de différentes implémentations d'objets de page est probablement meilleure (les frameworks peuvent bien le supporter maintenant; je ne les ai pas utilisés depuis un moment).

Continuez à refactoriser lorsque vous ajoutez d'autres scénarios. Si les marches sont trop grandes, divisez-les. Si les objets de page sont trop gros, divisez-les en widgets. J'aime organiser mes scénarios par capacités utilisateur / partie prenante (normalement liées au "quand" mais parfois au "alors") puis par différents contextes.

Donc, pour résumer:

1. Écrire un scénario vide
2. Écrivez le code pour le faire passer manuellement
3. câbler le scénario à l'aide de votre outil d'automatisation; il devrait maintenant fonctionner!
4. Écrivez un autre scénario, cette fois en écrivant l'automatisation avant le code de production
5. Refactoriser l'automatisation, en le déplaçant hors des étapes dans les objets de page
6. Continuez à refactoriser lorsque vous ajoutez d'autres scénarios.

Maintenant, vous avez un framework BDD entièrement câblé, et vous êtes dans un bon endroit pour continuer tout en le rendant maintenable.

Une dernière astuce

Pensez à cela comme une documentation vivante, plutôt que des tests. Les scénarios BDD ne ramassent presque jamais de bugs dans les bonnes équipes; tout ce qu'ils attrapent est généralement un problème de conception de code, alors adressez-le à ce niveau. Il aide les gens à comprendre ce que le code fait et ne fait pas encore, et pourquoi il est précieux.

La partie la plus importante de BDD est d'avoir les conversations sur le fonctionnement du code. Si vous automatisez des tests pour du code qui existe déjà, voyez si vous pouvez trouver quelqu'un à qui parler des bits compliqués, au moins, et vérifiez votre compréhension avec eux. Cela vous aidera également à utiliser la bonne langue dans les scénarios.

Voir mon publiez sur l'utilisation de BDD avec les systèmes hérités pour en savoir plus. Il y a beaucoup de conseils pour les débutants sur ce blog aussi.