Modello di progettazione COM per l’automazione con Selenium e Cucumber

Il Component Object Model (COM) è un design pattern che consente di strutturare i test nei progetti di automazione dei test. Ispirato al popolare Modello di Oggetti di Pagina (POM), il COM va oltre la gestione di intere pagine e si concentra su componenti UI specifici, come pulsanti, campi di testo, menu a discesa o altri elementi riutilizzabili.

In questo tutorial, spiegheremo come implementare il COM per testare un’applicazione web con Selenium WebDriver e Cucumber e come questo approccio possa rendere i tuoi test più flessibili, modulari e più facili da mantenere.

Cos’è il Component Object Model?

Il Component Object Model (COM) è un’evoluzione del modello POM. Invece di modellare un’intera pagina come un oggetto con metodi che interagiscono con tutti gli elementi della pagina, il COM suddivide l’interfaccia utente in componenti individuali, come:

• Pulsanti
• Campi di testo
• Menu a discesa
• Barre di ricerca
• Tabelle

Ogni componente è incapsulato in una classe Java, e le sue interazioni sono gestite da metodi specifici, permettendo a ciascun elemento di essere mantenuto e testato indipendentemente. Questo migliora la riutilizzabilità del codice, la manutenzione e la flessibilità nei test.

Perché Usare COM Al Posto di POM?

1. Maggiore Modularità

Con COM, ogni componente (come un pulsante o un campo di testo) è un’entità indipendente. Se un componente cambia (ad esempio, il testo di un pulsante cambia), è sufficiente modificare la classe del componente senza influenzare altri componenti o pagine. Ciò permette un’elevata modularità e evita la necessità di modificare intere pagine per aggiustamenti minori.

2. Riutilizzabilità e Flessibilità

I componenti possono essere riutilizzati su più pagine dell’applicazione, riducendo la duplicazione del codice. Ad esempio, un ButtonComponent può essere utilizzato su qualsiasi pagina in cui compare il pulsante, riducendo la ridondanza e aumentando la flessibilità nei test.

3. Manutenzione Semplificata

La manutenzione è più semplice con COM. Se un componente cambia (ad esempio, un pulsante o un campo di testo), è sufficiente modificare la classe che rappresenta quel componente. Tutti i test che utilizzano quel componente verranno automaticamente aggiornati senza dover riesaminare ciascuno scenario di test.

4. Adattato alle Interfacce Dinamiche

Le applicazioni moderne sono spesso dinamiche, con interfacce che cambiano frequentemente. COM è ideale per tali applicazioni perché consente il test dei componenti indipendentemente dall’interfaccia. Puoi modificare o aggiungere componenti senza influenzare i test per altre parti dell’applicazione.

5. Automazione dei test più veloce

COM accelera l’automazione dei test. Centralizzando le interazioni con i componenti in classi riutilizzabili, i tester non devono ridefinire le azioni per ogni pagina o componente. Ad esempio, una definizione a passaggio singolo per l’azione “clicca un pulsante” può essere utilizzata in tutti i test del progetto, riducendo significativamente il tempo necessario per automatizzare i test.

6. Evitare la ripetizione del lavoro tra i tester

Con COM, i tester non devono più ripetere lo stesso lavoro per ogni test. Le definizioni dei passaggi centralizzate per azioni comuni, come “clicca un pulsante” o “inserisci testo”, possono essere utilizzate da tutti i tester nel progetto. Questo garantisce coerenza nei test evitando ripetizioni inutili, migliorando l’efficienza e la collaborazione tra i tester.

Architettura del progetto COM

L’architettura di un progetto basato su COM è strutturata attorno a tre elementi principali: componenti, definizioni dei passaggi, e il runner.

1. Componenti

Ogni componente rappresenta un elemento dell’interfaccia utente, come un pulsante, un campo di testo o un menu a discesa. Queste classi racchiudono tutte le possibili interazioni con l’elemento.

Ecco un esempio della 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. Definizioni dei Passi

Le definizioni dei passi collegano i passi definiti nei file Gherkin ai metodi nei componenti. Sono responsabili dell’interazione con i componenti e dell’implementazione delle azioni specificate nello scenario di test.

Ecco un esempio di 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 è responsabile dell’esecuzione dei test utilizzando JUnit o TestNG. Configura Cucumber per caricare gli scenari di test definiti nei file .feature e per eseguirli utilizzando le definizioni dei passi.

Ecco un esempio di TestRunner:

@RunWith(Cucumber.class)

  @CucumberOptions(

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

          glue = "com.componentObjectModel.stepDefinitions",

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

)

  public class TestRunner {

​

  }

Scrivere e Spiegare uno Scenario Gherkin

Uno degli elementi essenziali dell’automazione con Cucumber è l’uso del linguaggio Gherkin per scrivere scenari di test. Gherkin consente di descrivere i test in modo leggibile e comprensibile, anche per persone non tecniche.

Consideriamo uno scenario in cui vogliamo testare l’interazione con un pulsante utilizzando il ButtonComponent che abbiamo definito in precedenza. Ecco come potrebbe essere scritto 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

Spiegazione dello Scenario

Scenario

Questo scenario descrive l’azione in cui un utente clicca sul pulsante ‘Invia’ sulla pagina di accesso e si assicura di essere reindirizzato alla homepage dopo aver cliccato.

• Dato che sono sulla pagina di accesso: Lo stato iniziale del test è che l’utente si trova sulla pagina di accesso.
• Quando clicco sul pulsante “Invia“: L’azione eseguita nel test è cliccare sul pulsante ‘Invia’.
• Quindi, dovrei essere reindirizzato alla homepage: La verifica attesa è che l’utente venga reindirizzato alla homepage dopo aver cliccato sul pulsante.

Collegamento con COM

Ogni passaggio in questo scenario è mappato in una definizione di passaggio in ButtonStepDefinition, dove l’azione di clic è gestita dal ButtonComponent, rendendo il test modulare e facile da mantenere.

Spiegazione Aggiuntiva

Si noti che i passaggi prendono il testo visualizzato sui pulsanti (o segnaposto nei campi di input, ecc.) come parametri. Ciò rende gli scenari più leggibili e generici. Ad esempio, nello scenario precedente, il testo del pulsante “Invia” viene utilizzato direttamente nel passaggio “Quando faccio clic sul pulsante ‘Invia.’” In questo modo, la stessa definizione del passaggio potrebbe essere riutilizzata per testare un altro pulsante, come “Login,” semplicemente modificando il testo nello scenario Gherkin. Questo migliora la riutilizzabilità del codice di test rendendo gli scenari più intuitivi e flessibili.

Riutilizzo dei Passaggi Con COM

Uno dei principali vantaggi di COM è la riutilizzabilità delle definizioni dei passaggi per diversi pulsanti. Ad esempio, lo stesso passaggio Quando faccio clic sul pulsante {string} può essere utilizzato per tutti i pulsanti, indipendentemente dal testo visualizzato sul pulsante. L’approccio COM consente di parametrizzare dinamicamente l’azione di clic in base al testo del pulsante.

Consideriamo un altro scenario con un pulsante diverso:

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 entrambi i casi, verrà utilizzato lo stesso metodo clickButton nel ButtonComponent, ma il testo del pulsante cambierà a seconda dello scenario. Questo dimostra come COM permette di riutilizzare lo stesso componente e la stessa definizione del passaggio, rendendo i test flessibili e modulari.

Come COM Migliora l’Automazione dei Test

Il COM migliora l’automazione dei test in diversi modi:

• Riduzione della duplicazione del codice: Utilizzando componenti riutilizzabili, si riduce la duplicazione del codice nei test. Ad esempio, un ButtonComponent utilizzato su più pagine dell’applicazione elimina la necessità di scrivere test ripetitivi.
• Test più leggibili e modificabili: I test sono più chiari e più facili da capire in quanto sono disaccoppiati dai dettagli di implementazione specifici della pagina. Puoi concentrarti sull’interazione con i componenti senza preoccuparti della struttura sottostante della pagina.
• Semplicità della manutenzione: Qualsiasi modifica a un componente (ad esempio, una modifica del testo del pulsante) influisce solo sulla classe del componente, non sui test. Ciò rende la manutenzione molto più semplice e veloce.
• Test più flessibili: I test possono essere facilmente adattati a interfacce utente in evoluzione, poiché i componenti sono indipendenti l’uno dall’altro. Puoi testare nuovi componenti o sostituire quelli esistenti senza influenzare altri test.

Quando è consigliato il pattern di progettazione COM?

Questo pattern di progettazione è consigliato se l’applicazione web in fase di test utilizza un sistema di progettazione unificato per tutti i componenti. Ad esempio, se tutti i pulsanti sono dichiarati allo stesso modo, con una struttura coerente per tutti gli elementi dell’interfaccia utente. In tali casi, utilizzando il COM è possibile centralizzare le interazioni con ciascun tipo di componente (come pulsanti, campi di testo, ecc.), rendendo i test più modulari, riutilizzabili e più facili da mantenere.

Riutilizzare le Definizioni dei Passaggi su Più Prodotti

Se stai sviluppando e testando più prodotti che utilizzano lo stesso sistema di design, puoi creare una libreria che includa tutte le definizioni dei passaggi e le azioni (o quasi tutte) per ciascun componente. Ciò consente ai tester di concentrarsi esclusivamente sulla scrittura degli scenari Gherkin e i test verranno automatizzati. Poiché tutti gli elementi web sono scritti allo stesso modo (HTML), componenti come pulsanti, campi di testo e altri elementi UI si comporteranno in modo coerente in tutti i progetti.

Come risultato, i tester non devono più ripetere le stesse attività: definire le definizioni dei passaggi e le azioni per componenti identici su più progetti. Questo approccio risparmia tempo e migliora la manutenibilità. Se un elemento web viene modificato (ad esempio, se cambia l’XPath), è sufficiente aggiornare quell’elemento nella libreria condivisa e la modifica verrà applicata automaticamente a tutti i progetti di automazione. Ciò riduce il rischio di errori e rende gli aggiornamenti più efficienti su diversi prodotti.

Conclusione

Il Component Object Model (COM) è un potente pattern di design per organizzare l’automazione dei test. Concentrandosi su componenti riutilizzabili, il COM consente di creare test più modulari, manutenibili e scalabili. Questo pattern è particolarmente utile per le applicazioni moderne, dove l’interfaccia utente cambia rapidamente e dove è essenziale interagire con componenti indipendenti.

Con test riutilizzabili, manutenzione semplificata e un’architettura flessibile, COM è la soluzione ideale per l’automazione dei test nei progetti Selenium e Cucumber.