Le Component Object Model (COM) est un modèle de conception qui vous permet de structurer les tests dans les projets d’automatisation des tests. Inspiré du populaire modèle Page Object Model (POM),, le COM va au-delà de la gestion de pages entières et se concentre sur des composants d’interface utilisateur spécifiques, tels que des boutons, des champs de texte, des menus déroulants ou d’autres éléments réutilisables.
Dans ce tutoriel, nous expliquerons comment implémenter le COM pour tester une application web avec Selenium WebDriver et Cucumber et comment cette approche peut rendre vos tests plus flexibles, modulaires et plus faciles à maintenir.
Qu’est-ce que le Component Object Model ?
Le Component Object Model (COM) est une évolution du modèle POM. Au lieu de modéliser une page entière comme un objet avec des méthodes interagissant avec tous les éléments de la page, le COM divise l’interface utilisateur en composants individuels, tels que :
- Boutons
- Champs de texte
- Menus déroulants
- Barres de recherche
- Tables
Chaque composant est encapsulé dans une classe Java, et ses interactions sont gérées par des méthodes spécifiques, permettant à chaque élément d’être maintenu et testé indépendamment. Cela améliore la réutilisabilité du code, la maintenance et la flexibilité dans les tests.
Pourquoi utiliser COM au lieu de POM ?
1. Modularité accrue
Avec COM, chaque composant (comme un bouton ou un champ de texte) est une entité indépendante. Si un composant change (par exemple, le texte d’un bouton change), vous avez seulement besoin de modifier la classe du composant sans affecter les autres composants ou pages. Cela permet une grande modularité et évite la nécessité de modifier des pages entières pour des ajustements mineurs.
2. Réutilisabilité et flexibilité
Les composants peuvent être réutilisés sur plusieurs pages de l’application, réduisant la duplication de code. Par exemple, un ButtonComponent
peut être utilisé sur n’importe quelle page où le bouton apparaît, réduisant la redondance et augmentant la flexibilité des tests.
3. Maintenance simplifiée
La maintenance est plus facile avec COM. Si un composant change (par exemple, un bouton ou un champ de texte), vous avez seulement besoin de modifier la classe représentant ce composant. Tous les tests utilisant ce composant seront automatiquement mis à jour sans avoir à revoir chaque scénario de test.
4. Adapté aux interfaces dynamiques
Les applications modernes sont souvent dynamiques, avec des interfaces changeantes. COM est idéal pour de telles applications car il permet de tester des composants de manière indépendante de l’interface. Vous pouvez modifier ou ajouter des composants sans affecter les tests pour d’autres parties de l’application.
5. Automatisation des tests plus rapide
COM accélère l’automatisation des tests. En centralisant les interactions avec les composants dans des classes réutilisables, les testeurs n’ont pas besoin de redéfinir les actions pour chaque page ou composant. Par exemple, une étape unique de la définition de l’action « cliquer sur un bouton » peut être utilisée dans tous les tests du projet, réduisant ainsi considérablement le temps nécessaire pour automatiser les tests.
6. Éviter la répétition du travail entre les testeurs
Avec COM, les testeurs n’ont plus besoin de répéter le même travail pour chaque test. Les étapes centralisées pour les actions courantes, telles que « cliquer sur un bouton » ou « entrer du texte », peuvent être utilisées par tous les testeurs du projet. Cela garantit la cohérence des tests tout en évitant les répétitions inutiles, améliorant ainsi l’efficacité et la collaboration entre les testeurs.
Architecture de projet COM
L’architecture d’un projet basé sur COM est structurée autour de trois éléments principaux : composants, étapes, et le runner.
1. Composants
Chaque composant représente un élément d’interface utilisateur, tel qu’un bouton, un champ de texte ou un menu déroulant. 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. Définitions d’étapes
Les définitions d’étapes lient les étapes définies dans les fichiers Gherkin aux méthodes des composants. Ils 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. Exécuteur
La classe exécuteur est responsable de l’exécution des tests à l’aide de JUnit ou TestNG. Il configure Cucumber pour charger les scénarios de test définis dans les fichiers .feature
et les exécuter à l’aide des définitions d’étapes.
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 {
}
Rédaction 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. Gherkin vous permet de décrire les tests de manière lisible et compréhensible, même pour les non-techniciens.
Considérons un scénario où nous voulons tester l’interaction avec un bouton en utilisant le ButtonComponent
que nous avons 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
Scénario
Ce scénario décrit l’action où un utilisateur clique sur le bouton « Soumettre » sur la page de connexion et s’assure d’être redirigé vers la page d’accueil après avoir cliqué.
- Étant donné que je suis sur la page de connexion: L’état initial du test est que l’utilisateur se trouve sur la page de connexion.
- Lorsque je clique sur le bouton « Soumettre »« : L’action effectuée dans le test est de cliquer sur le bouton « Soumettre ».
- Alors, je devrais être redirigé vers la page d’accueil: La vérification attendue est que l’utilisateur est redirigé vers la page d’accueil après avoir cliqué sur le bouton.
Lien Avec COM
Chaque étape de ce scénario est associée à une définition d’étape dans ButtonStepDefinition
, où l’action de clic est gérée par le composant ButtonComponent
, rendant le test modulaire et facile à maintenir.
Explication Additionnelle
Remarquez que les étapes prennent le texte affiché sur les boutons (ou les espaces réservés dans les champs de saisie, etc.) en tant que paramètres. Cela rend les scénarios plus lisibles et génériques. Par exemple, dans le scénario ci-dessus, le texte du bouton « Soumettre » est utilisé directement dans l’étape « Quand je clique sur le bouton ‘Soumettre’. » De cette manière, la même définition d’étape pourrait être réutilisée pour tester un autre bouton, tel que « Connexion, » en changeant 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.
Réutilisabilité des étapes avec COM
L’un des principaux avantages de COM est la réutilisabilité des définitions d’étape pour différents boutons. Par exemple, la même étape Quand je clique sur le bouton {string}
peut être utilisée pour tous les boutons, indépendamment du texte affiché sur le bouton. L’approche COM vous permet de paramétrer dynamiquement l’action de clic en fonction du texte du bouton.
Prenons en considération un autre scénario avec un bouton différent :
Scénario
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 le ButtonComponent
sera utilisée, mais le texte du bouton changera en fonction du scénario. Cela démontre comment COM permet de réutiliser le même composant et la même définition d’étape, rendant les tests flexibles et modulaires.
Comment COM améliore l’automatisation des tests
COM améliore l’automatisation des tests de plusieurs façons :
- 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é sur plusieurs pages de l’application élimine le besoin d’écrire des tests répétitifs. - Tests plus lisibles et modifiables : Les tests sont plus clairs et plus faciles à comprendre car ils sont dissociés des détails de l’implémentation spécifique à la page. Vous pouvez vous concentrer sur l’interaction avec les composants sans vous soucier de la structure sous-jacente de la page.
- Facilité de maintenance : Toute modification apportée à un composant (par exemple, un changement de texte de bouton) n’affecte que la classe du composant, pas les tests. Cela rend la maintenance beaucoup plus simple et rapide.
- Tests plus flexibles : Les tests peuvent facilement s’adapter aux changements d’interfaces utilisateur, car les composants sont indépendants les uns des autres. Vous pouvez tester de nouveaux composants ou remplacer des composants existants sans affecter les autres tests.
Quand le modèle de conception COM est-il recommandé ?
Ce modèle de conception est recommandé si l’application web testée utilise un système de conception unifié pour tous les composants. Par exemple, si tous les boutons sont déclarés de la même manière, avec une structure cohérente pour tous les éléments de l’interface utilisateur. Dans de tels cas, l’utilisation de COM vous permet de centraliser les interactions avec chaque type de composant (comme les boutons, les champs de texte, etc.), rendant les tests plus modulaires, réutilisables et plus faciles à entretenir.
Réutilisation des définitions d’étapes à travers plusieurs produits
Si vous développez et testez plusieurs produits qui utilisent le même système de conception, vous pouvez créer une bibliothèque qui englobe toutes les définitions d’étapes et actions (ou presque toutes) pour chaque composant. Cela permet aux testeurs de se concentrer uniquement sur l’écriture de scénarios Gherkin, et les tests seront automatisés. Comme tous les éléments web sont écrits de la même manière (HTML), des composants tels que les boutons, les champs de texte et autres éléments d’interface utilisateur se comporteront de manière cohérente dans tous les projets.
En conséquence, les testeurs n’ont plus besoin de répéter les mêmes tâches – définir les définitions d’étapes et les actions pour des composants identiques à travers plusieurs projets. Cette approche permet de gagner du temps et d’améliorer la maintenabilité. Si un élément web est modifié (par exemple, si le XPath change), vous devez simplement mettre à jour cet élément dans la bibliothèque 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 à travers différents produits.
Conclusion
Le Modèle d’Objet de Composant (COM) est un puissant modèle de conception pour organiser l’automatisation des tests. En se concentrant sur des composants réutilisables, le COM vous permet de créer des tests plus modulaires, maintenables et évolutifs. Ce modèle est particulièrement utile pour les applications modernes, où l’interface utilisateur évolue 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, COM est la solution idéale pour l’automatisation des tests dans les projets Selenium et Cucumber.
Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber