Le Design Pattern COM pour l’Automatisation avec Selenium et Cucumber

Mise à jour le 9 janvier 2025

Cet article est une adaptation d’un article original de Mr Lassaad Ben Rejeb ,Expert en automatisation des tests, publié sur Medium

Le Component Object Model (COM) est un modèle de conception (design pattern) qui permet de structurer les tests dans des projets d’automatisation de tests. Inspiré du populaire Page Object Model (POM), le COM va au-delà de la simple gestion des pages complètes et se concentre sur des composants spécifiques de l’interface utilisateur, tels que des boutons, des champs de texte, des menus déroulants ou d’autres éléments réutilisables.

Dans ce tutoriel, nous allons expliquer comment mettre en œuvre le Component Object Model (COM) pour tester une application web avec Selenium WebDriver et Cucumber, et comment cette approche peut rendre vos tests plus flexibles, modulaires et faciles à maintenir.

Qu’est-ce que le COM (Component Object Model) ?

Le Component Object Model (COM) est une évolution du modèle POM. Plutôt que de modéliser une page entière comme un objet avec des méthodes qui interagissent avec tous les éléments de la page, le COM divise l’interface utilisateur en composants individuels, comme :

Boutons
Champs de texte
Menus déroulants
Barres de recherche
Tableaux

Chaque composant est encapsulé dans une classe Java, et ses interactions sont gérées par des méthodes spécifiques, ce qui permet de maintenir et de tester chaque élément indépendamment. Cela améliore la réutilisabilité du code, la facilité de maintenance et la flexibilité dans les tests.

Pourquoi utiliser le COM plutôt que le POM ?

1. Modularité accrue

Avec le COM, chaque composant (comme un bouton ou un champ de texte) est une entité indépendante. Si un composant change (par exemple, un bouton change de texte), vous n’avez qu’à modifier la classe du composant sans avoir à toucher aux autres composants ou aux pages. Cela permet de maintenir une grande modularité et d’éviter de modifier des pages entières pour des ajustements mineurs.

2. Réutilisation et flexibilité

Les composants peuvent être réutilisés dans plusieurs pages de l’application, ce qui évite de dupliquer le code à chaque nouvelle page. Par exemple, un ButtonComponent peut être utilisé dans toutes les pages où ce bouton apparaît, réduisant ainsi la duplication et augmentant la flexibilité des tests.

3. Maintenance simplifiée

La maintenance devient plus simple avec le COM. Si un composant change (par exemple, un bouton ou un champ de texte), vous n’avez qu’à modifier la classe représentant ce composant. Tous les tests qui utilisent ce composant sont automatiquement mis à jour, sans avoir besoin de revisiter chaque scénario de test.

4. Adapté aux interfaces dynamiques

Les applications modernes sont souvent dynamiques, avec des interfaces qui changent fréquemment. Le COM est idéal pour ces types d’applications, car il permet de tester des composants indépendants de l’interface. Vous pouvez modifier ou ajouter des composants sans affecter les tests des autres parties de l’application.

5. Rapidité d’automatisation des tests

Le Component Object Model (COM) permet d’accélérer l’automatisation des tests. En centralisant les interactions avec les composants dans des classes réutilisables, les testeurs n’ont pas à redéfinir les actions pour chaque page ou composant. Par exemple, une seule step definition pour l’action « cliquer sur un bouton » peut être utilisée dans tous les tests du projet, ce qui réduit le temps nécessaire pour automatiser les tests.

6. Non-répétition du travail entre les testeurs

Avec le Component Object Model (COM), les testeurs n’ont plus à répéter le même travail pour chaque test. Les step definitions centralisées pour des actions communes, comme « cliquer sur un bouton » ou « entrer du texte », peuvent être utilisées par tous les testeurs du projet. Cela garantit une uniformité des tests tout en évitant les répétitions inutiles, ce qui améliore l’efficacité et la collaboration entre les testeurs.

Architecture du Projet COM

L’architecture du projet utilisant COM est structurée autour de trois éléments principaux : les composants, les step definitions et le runner.

1. Composants

Chaque composant représente un élément de l’interface utilisateur, comme un bouton, un champ de texte ou une liste déroulante. Ces classes encapsulent toutes les interactions possibles avec l’élément.
Voici un exemple de la classe ButtonComponent :

public class ButtonComponent {
private WebDriver driver;
public ButtonComponent(WebDriver driver) {
this.driver = driver;
}
public void clickButton(String buttonText) {
WebElement button =
driver.findElement(By.xpath("//button[text()='" + buttonText + "']"));
button.click();
}
}

2. Step Definitions

Les step definitions lient les étapes définies dans les fichiers Gherkin aux méthodes des composants. Elles sont responsables de l’interaction avec les composants et de la mise en œuvre des actions spécifiées dans le scénario de test.
Voici un exemple de ButtonStepDefinition :

public class ButtonStepDefinition {
private ButtonComponent buttonComponent;
public ButtonStepDefinition(WebDriver driver) { this.buttonComponent = new ButtonComponent(driver);
}
@When("I click on the button {string}") public void iClickOnTheButton(String buttonText) {
buttonComponent.clickButton(buttonText); }
}

3. Runner

La classe runner est responsable de l’exécution des tests en utilisant JUnit ou TestNG. Elle configure Cucumber pour charger les scénarios de test définis dans les fichiers
.feature et les exécuter en utilisant les step definitions.
Voici un exemple de TestRunner :

@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/resources/features",
glue = "com.componentObjectModel.stepDefinitions", plugin = {"pretty", "html:target/cucumber-
reports.html"}
)
public class TestRunner {
}

Écriture et Explication d’un Scénario Gherkin

Un des éléments essentiels de l’automatisation avec Cucumber est l’utilisation du langage Gherkin pour écrire des scénarios de test. Le Gherkin permet de décrire les tests de manière lisible et compréhensible, même pour les personnes non techniques. Prenons un scénario où l’on souhaite tester l’interaction avec un bouton, en utilisant le ButtonComponent que nous avons défini plus tôt.

Voici comment cela pourrait être écrit en Gherkin :

Scenario: User clicks on the "Submit" button
Given I am on the login page
When I click on the button "Submit"
Then I should be redirected to the homepage

Explication du scénario :

Scenario : Ce scénario décrit l’action où un utilisateur clique sur le bouton « Submit » sur la page de connexion et s’assure qu’il est redirigé vers la page
d’accueil après avoir cliqué.

Given I am on the login page : L’état initial du test est que l’utilisateur est sur la page de connexion.
When I click on the button « Submit » : L’action effectuée dans le test est le clic sur le bouton « Submit ».
Then I should be redirected to the homepage : La vérification attendue est que l’utilisateur est redirigé vers la page d’accueil après avoir cliqué sur le bouton.

Lien avec le COM :

Chaque étape de ce scénario est mappée sur une step definition dans ButtonStepDefinition, où l’action du clic est prise en charge par le ButtonComponent, rendant le test modulaire et facile à maintenir.

Explication supplémentaire

On peut remarquer que les étapes utilisent comme paramètres les textes affichés sur les boutons (ou les placeholder dans les champs input, etc.). Cela permet de rendre les scénarios plus lisibles et génériques. Par exemple, dans le scénario ci-dessus, le texte du bouton « Submit » est utilisé directement dans l’étape « When I click on the button
‘Submit' ». De cette manière, ce même step definition pourrait être réutilisé pour tester un autre bouton, comme « Login », en modifiant simplement le texte dans le scénario Gherkin. Cela améliore la réutilisabilité du code de test, tout en rendant les scénarios plus intuitifs et flexibles.

La réutilisation des étapes avec le COM

L’un des avantages majeurs du COM est la réutilisabilité des step definitions pour différents boutons. Par exemple, la même étape When I click on the button {string} peut être utilisée pour tous les boutons, indépendamment du texte affiché sur le bouton. L’approche COM permet de paramétrer dynamiquement l’action de clic en fonction du texte du bouton.

Prenons un autre scénario avec un autre bouton :

Scenario: User clicks on the "Login" button
Given I am on the login page
When I click on the button "Login"
Then I should be redirected to the dashboard

Dans les deux cas, la même méthode clickButton dans ButtonComponent sera utilisée, mais le texte du bouton changera selon le scénario. Cela démontre à quel point le COM permet de réutiliser le même composant et la même step definition, rendant ainsi les tests flexibles et modulaires.

Comment le COM améliore l’Automatisation des Tests

Le COM améliore l’automatisation des tests de plusieurs façons :

1. Réduction de la duplication de code : En utilisant des composants réutilisables, vous réduisez la duplication de code dans les tests. Par exemple, un ButtonComponent utilisé dans plusieurs pages de l’application évite d’écrire des tests répétitifs.

2. Tests plus lisibles et modifiables : Les tests sont plus clairs et plus faciles à comprendre, car ils sont découplés des détails d’implémentation spécifiques à chaque page. Vous pouvez vous concentrer sur l’interaction avec les composants, sans vous soucier de la structure sous-jacente des pages.

3. Facilité de maintenance : Toute modification d’un composant (par exemple, un bouton qui change de texte) n’affecte que la classe du composant, pas les tests. Cela rend le processus de maintenance beaucoup plus simple et rapide.

4. Tests plus flexibles : Les tests peuvent facilement être adaptés à des interfaces utilisateur changeantes, car les composants sont indépendants les uns des autres. Vous pouvez tester de nouveaux composants ou remplacer des composants existants sans perturber les autres tests.

Dans quel cas le design pattern COM est-il recommandé ?

Ce design pattern est recommandé si l’application web à tester utilise un design system unique pour tous les composants. Cela signifie que, par exemple, tous les boutons sont déclarés de la même manière, avec une structure uniforme pour tous les éléments de l’interface utilisateur. Dans ce cas, l’utilisation du COM vous permet de centraliser l’interaction avec chaque type de composant (comme les boutons, champs de texte, etc.), rendant les tests plus modulaires, réutilisables et faciles à maintenir.

Réutilisation des Step Definitions dans plusieurs produits

Si vous développez et testez plusieurs produits qui utilisent le même design system, vous pouvez créer une librairie qui englobe tous les step definitions et les actions (ou presque) pour chaque composant. Cela permet aux testeurs de se concentrer uniquement sur l’écriture des scénarios Gherkin, et les tests seront automatisés.

Comme tous les éléments web sont écrits de la même manière (HTML), les composants comme les boutons, champs de texte et autres éléments d’interface auront un comportement cohérent à travers tous les projets.

Ainsi, les testeurs n’ont plus besoin de répéter les mêmes actions—déclarer les step definitions et les actions pour des composants identiques dans plusieurs projets. Cette approche permet de gagner du temps et améliore la maintenabilité. Si un élément web est modifié (par exemple, le XPath), il suffit de mettre à jour cet élément dans la librairie partagée, et la modification sera automatiquement appliquée à tous les projets d’automatisation. Cela réduit le risque d’erreurs et rend les mises à jour plus efficaces dans les différents produits.

Conclusion

Le Component Object Model (COM) est un modèle de conception puissant pour organiser les tests d’automatisation. En se concentrant sur des composants réutilisables, le COM permet de créer des tests plus modulaires, plus faciles à maintenir et évolutifs. Ce modèle est particulièrement adapté aux applications modernes, où l’interface utilisateur change rapidement, et où l’interaction avec des composants indépendants est essentielle.

Avec des tests réutilisables, une maintenance simplifiée et une architecture flexible, le COM est la solution idéale pour l’automatisation des tests dans les projets Selenium et Cucumber.