COM Designpatroon voor Automatisering met Selenium en Komkommer

Het Component Object Model (COM) is een ontwerppatroon dat het mogelijk maakt om tests te structureren in testautomatiseringsprojecten. Geïnspireerd door het populaire Page Object Model (POM), gaat COM verder dan het behandelen van hele pagina’s en richt zich op specifieke UI-componenten, zoals knoppen, tekstvelden, vervolgkeuzemenu’s of andere herbruikbare elementen.

In deze zelfstudie zullen we uitleggen hoe COM geïmplementeerd kan worden om een webtoepassing te testen met Selenium WebDriver en Cucumber en hoe deze aanpak je tests flexibeler, modulair en gemakkelijker te onderhouden kan maken.

Wat is het Component Object Model?

Het Component Object Model (COM) is een evolutie van het POM-model. In plaats van een hele pagina te modelleren als een object met methoden die interageren met alle pagina-elementen, verdeelt COM de gebruikersinterface in individuele componenten, zoals:

• Knoppen
• Tekstvelden
• Vervolgkeuzemenu’s
• Zoekbalken
• Tabels

Elke component is ingekapseld in een Java-klasse, en de interacties worden beheerd door specifieke methoden, waardoor elk element onafhankelijk kan worden onderhouden en getest. Dit verbetert de herbruikbaarheid van code, onderhoud en flexibiliteit in tests.

Waarom COM gebruiken in plaats van POM?

1. Verhoogde Modulariteit

Met COM is elke component (zoals een knop of tekstveld) een onafhankelijke entiteit. Als een component verandert (bijvoorbeeld, de tekst van een knop verandert), hoef je alleen de componentklasse aan te passen zonder andere componenten of pagina’s te beïnvloeden. Dit zorgt voor een hoge modulariteit en voorkomt dat je hele pagina’s moet aanpassen voor kleine wijzigingen.

2. Herbruikbaarheid en Flexibiliteit

Componenten kunnen op meerdere pagina’s van de applicatie worden hergebruikt, wat de codeduplicatie vermindert. Bijvoorbeeld, een ButtonComponent kan op elke pagina worden gebruikt waar de knop verschijnt, wat redundantie vermindert en de testflexibiliteit vergroot.

3. Vereenvoudigd Onderhoud

Onderhoud is gemakkelijker met COM. Als een component verandert (bijvoorbeeld, een knop of tekstveld), hoef je alleen de klasse die die component vertegenwoordigt aan te passen. Alle tests die die component gebruiken, worden automatisch bijgewerkt zonder dat je elk testscenario opnieuw hoeft te bekijken.

4. Aangepast aan Dynamische Interfaces

Moderne applicaties zijn vaak dynamisch, met interfaces die vaak veranderen. COM is ideaal voor dergelijke applicaties omdat het het testen van componenten onafhankelijk van de interface mogelijk maakt. Je kunt componenten aanpassen of toevoegen zonder de tests voor andere delen van de applicatie te beïnvloeden.

5. Snellere Testautomatisering

COM versnelt de testautomatisering. Door interacties met componenten te centraliseren in herbruikbare klassen, hoeven testers acties niet opnieuw te definiëren voor elke pagina of component. Bijvoorbeeld, een enkele-stap definitie voor de actie “klik op een knop” kan in alle tests van het project worden gebruikt, wat de tijd die nodig is om tests te automatiseren aanzienlijk vermindert.

6. Voorkomen van Herhaling van Werk Tussen Testers

Met COM hoeven testers niet langer hetzelfde werk voor elke test te herhalen. Gecentraliseerde stapdefinities voor veelvoorkomende acties, zoals “klik op een knop” of “voer tekst in,” kunnen door alle testers in het project worden gebruikt. Dit zorgt voor consistentie in de tests en voorkomt onnodige herhaling, wat de efficiëntie en samenwerking tussen testers verbetert.

COM Projectarchitectuur

De architectuur van een op COM gebaseerde project is gestructureerd rond drie hoofdcomponenten: componenten, stapdefinities, en de runner.

1. Componenten

Elk component vertegenwoordigt een UI-element, zoals een knop, tekstveld of vervolgkeuzemenu. Deze klassen omvatten alle mogelijke interacties met het element.

Hier is een voorbeeld van de klasse 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. Stapdefinities

Stapdefinitieskoppelen de stappen die gedefinieerd zijn in de Gherkin-bestanden aan de methoden in de componenten. Ze zijn verantwoordelijk voor de interactie met de componenten en het implementeren van de acties die gespecificeerd zijn in het testscenario.

Hier is een voorbeeld van 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. Uitvoerder

De uitvoerder klasse is verantwoordelijk voor het uitvoeren van de tests met behulp van JUnit of TestNG. Het configureert Cucumber om de testscenario’s die gedefinieerd zijn in de .feature-bestanden te laden en ze uit te voeren met behulp van de stapdefinities.

Hier is een voorbeeld van TestRunner:

@RunWith(Cucumber.class)

  @CucumberOptions(

          features = "src/test/resources/features",

          glue = "com.componentObjectModel.stepDefinitions",

          plugin = {"pretty", "html:target/cucumber-reports.html"}

)

  public class TestRunner {

​

  }

Het schrijven en uitleggen van een Gherkin-scenario

Een van de essentiële elementen van automatisering met Cucumber is het gebruik van de Gherkin-taal om testscenario’s te schrijven. Gherkin stelt je in staat om tests op een leesbare en begrijpelijke manier te beschrijven, zelfs voor niet-technische mensen.

Laten we een scenario bekijken waar we de interactie met een knop willen testen met behulp van de ButtonComponent die we eerder hebben gedefinieerd. Zo zou het geschreven kunnen worden in 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

Uitleg van het Scenario

Scenario

Dit scenario beschrijft de actie waarbij een gebruiker op de knop ‘Verzenden’ op de inlogpagina klikt en ervoor zorgt dat ze na het klikken worden doorgestuurd naar de startpagina.

• Aangezien ik op de inlogpagina ben: De initiële staat van de test is dat de gebruiker op de inlogpagina is.
• Wanneer ik op de knop “Verzenden” klik: De actie die in de test wordt uitgevoerd, is het klikken op de knop ‘Verzenden’.
• Dan zou ik moeten worden doorgestuurd naar de startpagina: De verwachte verificatie is dat de gebruiker na het klikken op de knop naar de startpagina wordt doorgestuurd.

Koppeling met COM

Elke stap in dit scenario is gekoppeld aan een stapdefinitie in ButtonStepDefinition, waarbij de klikactie wordt afgehandeld door de ButtonComponent, waardoor de test modulair en gemakkelijk te onderhouden is.

Extra Uitleg

Let op dat de stappen de weergegeven tekst op de knoppen (of plaatsaanduidingen in invoervelden, etc.) als parameters gebruiken. Dit maakt de scenario’s meer leesbaar en generiek. Bijvoorbeeld, in het bovenstaande scenario wordt de tekst van de knop “Verzenden” direct gebruikt in de stap “Wanneer ik op de knop ‘Verzenden.’” Op deze manier kan dezelfde stapdefinitie opnieuw worden gebruikt om een andere knop te testen, zoals “Inloggen,” door simpelweg de tekst in het Gherkin-scenario te wijzigen. Dit verbetert de herbruikbaarheid van de testcode en maakt de scenario’s intuïtiever en flexibeler.

Herbruikbaarheid van Stappen Met COM

Een van de belangrijkste voordelen van COM is de herbruikbaarheid van stapdefinities voor verschillende knoppen. Bijvoorbeeld, dezelfde stap Wanneer ik op de knop {string} klik kan voor alle knoppen worden gebruikt, ongeacht de weergegeven tekst op de knop. De COM-benadering stelt je in staat om de klikactie dynamisch te parametriseren op basis van de knoptekst.

Laten we een ander scenario overwegen met een andere knop:

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

In beide gevallen, zal dezelfde clickButton methode in de ButtonComponent worden gebruikt, maar de knoptekst zal veranderen afhankelijk van het scenario. Dit toont aan hoe COM het mogelijk maakt om dezelfde component en stapdefinitie opnieuw te gebruiken, waardoor tests flexibel en modulair worden.

Hoe COM Testautomatisering Verbeterd

COM verbetert testautomatisering op verschillende manieren:

• Vermindering van code duplicatie: Door herbruikbare componenten te gebruiken, verminder je code duplicatie in tests. Bijvoorbeeld, een ButtonComponent die op meerdere pagina’s van de applicatie wordt gebruikt, elimineert de noodzaak om repetitieve tests te schrijven.
• Leesbaardere en aanpasbare tests: Tests zijn duidelijker en gemakkelijker te begrijpen omdat ze losgekoppeld zijn van pagina-specifieke implementatiedetails. Je kunt je concentreren op het interactie met componenten zonder je zorgen te maken over de onderliggende paginastructuur.
• Gemak van onderhoud: Elke wijziging aan een component (bijv. een wijziging van de knoptekst) beïnvloedt alleen de componentklasse, niet de tests. Dit maakt het onderhoud veel eenvoudiger en sneller.
• Flexibeler tests: Tests kunnen eenvoudig worden aangepast aan veranderende UI’s, aangezien componenten onafhankelijk van elkaar zijn. Je kunt nieuwe componenten testen of bestaande vervangen zonder andere tests te beïnvloeden.

Wanneer wordt het COM-ontwerppatroon aanbevolen?

Dit ontwerppatroon wordt aanbevolen als de webapplicatie die wordt getest een uniform ontwerpsysteem voor alle componenten gebruikt. Bijvoorbeeld, als alle knoppen op dezelfde manier worden gedeclareerd, met een consistente structuur voor alle UI-elementen. In dergelijke gevallen maakt het gebruik van COM het mogelijk om interacties met elk type component (zoals knoppen, tekstvelden, enz.) te centraliseren, waardoor tests modulairder, herbruikbaarder en gemakkelijker te onderhouden zijn.

Hergebruik van Stappendefinities Over Meerdere Producten

Als je meerdere producten ontwikkelt en test die hetzelfde ontwerpsysteem gebruiken, kun je een bibliotheek maken die alle stappendefinities en acties (of bijna allemaal) voor elk component omvat. Hierdoor kunnen testers zich uitsluitend richten op het schrijven van Gherkin-scenario’s, en zullen de tests geautomatiseerd worden. Aangezien alle webelementen op dezelfde manier worden geschreven (HTML), zullen componenten zoals knoppen, tekstvelden en andere UI-elementen consistent gedragen over alle projecten.

Als gevolg hiervan hoeven testers niet langer dezelfde taken te herhalen — het definiëren van stappen en acties voor identieke componenten over meerdere projecten. Deze aanpak bespaart tijd en verbetert de onderhoudbaarheid. Als een webelement wordt gewijzigd (bijvoorbeeld als de XPath verandert), hoef je alleen dat element bij te werken in de gedeelde bibliotheek, en de wijziging wordt automatisch toegepast op alle automatiseringsprojecten. Dit vermindert het risico op fouten en maakt updates efficiënter over verschillende producten.

Conclusie

Het Component Object Model (COM) is een krachtig ontwerppatroon voor het organiseren van testautomatisering. Door te focussen op herbruikbare componenten, stelt COM je in staat om meer modulaire, onderhoudbare en schaalbare tests te maken. Dit patroon is bijzonder nuttig voor moderne applicaties, waar de gebruikersinterface snel verandert en waar interactie met onafhankelijke componenten essentieel is.

Met herbruikbare tests, vereenvoudigd onderhoud en een flexibele architectuur is COM de ideale oplossing voor testautomatisering in Selenium– en Cucumber-projecten.