Le Component Object Model (COM)

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

Mise à jour le 28 juillet 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

D’un point de vue pratique, avec le Component Object Model (COM), les testeurs n’ont plus à répéter le même travail pour chaque test. En outre, 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. De ce fait, 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

L’un des éléments essentiels de l’automatisation avec Cucumber réside dans l’utilisation du langage Gherkin. Ce langage permet d’écrire des scénarios de test de manière lisible et compréhensible, y compris pour les profils non techniques.

Tout d’abord, Gherkin repose sur une syntaxe simple qui décrit les actions attendues dans un scénario. Par conséquent, il facilite la collaboration entre les testeurs, développeurs et parties prenantes.

Prenons un exemple concret : imaginons un scénario qui teste l’interaction avec un bouton. Pour cela, nous allons utiliser le ButtonComponent défini précédemment.

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 : Le scénario décrit l’action d’un utilisateur qui clique sur le bouton « Submit » sur la page de connexion et qui se redirige vers la page d’accueil.

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 : Le test vérifie que l’utilisateur arrive bien sur la page d’accueil après avoir cliqué sur le bouton.

Lien avec le COM :

Chaque étape de ce scénario correspond à une step definition dans ButtonStepDefinition. Le ButtonComponent prend en charge l’action du clic, ce qui rend le test modulaire et facile à maintenir.

Explication supplémentaire

On remarque que les étapes utilisent comme paramètres les textes affichés sur les boutons (ou les placeholders dans les champs input, etc.). Cela rend les scénarios plus lisibles et génériques. Par exemple, dans le scénario ci-dessus, le texte du bouton « Submit » sert directement dans l’étape « When I click on the button ‘Submit' ». De cette manière, on peut réutiliser ce même step definition pour tester un autre bouton, comme « Login », en modifiant simplement le texte dans le scénario Gherkin. Cette méthode 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, on peut utiliser la même étape When I click on the button {string} pour tous les boutons, quel que soit le texte affiché. 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. Cependant, le texte du bouton changera selon le scénario. Cela montre clairement que le COM permet de réutiliser un même composant et la même step definition. Ainsi, les tests deviennent 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é ?

On recommande ce design pattern lorsque l’application web utilise un design system unique pour tous les composants. Par exemple, les développeurs déclarent tous les boutons de la même manière. Ils ont 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.). Cela rend les tests plus modulaires, réutilisables et faciles à maintenir.

Réutilisation des Step Definitions dans plusieurs produits

Lorsque vous testez plusieurs produits partageant le même design system, il est possible de créer une librairie commune. Cette librairie regroupe toutes les step definitions et les actions associées pour chaque type de composant.

Les testeurs peuvent alors se concentrer uniquement sur l’écriture des scénarios Gherkin. La librairie définit déjà les composants qui automatisent les actions.

Puisque les éléments HTML suivent une structure cohérente, les composants comme les boutons ou les champs de texte fonctionnent de la même façon partout. Ainsi, il devient inutile de redéfinir les actions pour chaque projet.

Un simple changement — comme une mise à jour du XPath — dans la librairie partagée se propage à tous les tests. Cela évite les erreurs, réduit le travail redondant et simplifie la maintenance des tests sur l’ensemble des produits.

Conclusion

Le Component Object Model (COM) est un modèle de conception efficace pour structurer les tests d’automatisation. Il repose sur l’usage de composants réutilisables, ce qui rend les tests plus modulaires, faciles à maintenir et évolutifs.

Ce pattern convient particulièrement aux applications modernes, dont l’interface utilisateur évolue fréquemment. En testant chaque composant de manière indépendante, le COM garantit une grande souplesse.

Grâce à sa réutilisabilité, à la centralisation des interactions et à son architecture claire, le COM s’impose comme une solution idéale pour les projets Selenium et Cucumber.