Uno sguardo al passato: l'evoluzione dell'automazione dei test

Jecelyn Yeen

Maksim Sadym

La nascita dell'automazione dei test

Torniamo indietro agli anni'90, quando è nato il browser web. L'automazione dei test è diventata realtà solo negli anni 2000, con l'emergere dei progetti Selenium e WebDriver per affrontare le sfide dei test su più browser e dispositivi.

Questi due progetti si sono uniti nel 2011 come Selenium WebDriver e sono diventati uno standard W3C nel 2018. Di solito lo chiamiamo WebDriver o WebDriver "classico".

L'automazione dei test prima di WebDriver "classico" era piuttosto complicata. La possibilità di automatizzare i test del browser ha migliorato notevolmente la qualità della vita di sviluppatori e tester.

L'ascesa di JavaScript

Con l'evoluzione dello sviluppo web, che si basa sempre di più su JavaScript, sono emerse nuove soluzioni di automazione come WebdriverIO, Appium, Nightwatch, Protractor (inutilizzato), Testcafe, Cypress, Puppeteer e Playwright.

Approcci di automazione

In linea di massima, questi strumenti possono essere organizzati in due gruppi principali in base al modo in cui automatizzano i browser:

• Alto livello: strumenti che eseguono JavaScript all'interno del browser. Ad esempio, Cypress e TestCafe sfruttano le API web e Node.js per eseguire i test direttamente nel browser. Un fatto divertente: anche la prima versione di Selenium utilizzava lo stesso approccio.
• A basso livello: strumenti che eseguono comandi remoti al di fuori del browser. Quando gli strumenti richiedono un controllo ancora maggiore, ad esempio l'apertura di più schede o la simulazione della modalità del dispositivo, devono eseguire comandi remoti per controllare il browser tramite protocolli. I due principali protocolli di automazione sono WebDriver "classico" e Chrome DevTools Protocol (CDP).

Nella sezione successiva esamineremo questi due protocolli per comprenderne i punti di forza e le limitazioni.

WebDriver "classico" e Chrome DevTools Protocol (CDP)

WebDriver "classico" è uno standard web supportato da tutti i principali browser. Gli script di automazione inviano comandi tramite richieste HTTP a un server del driver, che poi comunica con i browser tramite protocolli interni specifici del browser.

Sebbene abbia un eccellente supporto multibrowser e le sue API siano progettate per i test, può essere lento e non supporta alcuni controlli di basso livello.

Ad esempio, immagina di avere uno script di test che fa clic su un elemento await coffee.click();. Viene tradotto in una serie di richieste HTTP.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

D'altra parte, il protocollo Chrome DevTools (CDP) è stato inizialmente progettato per Chrome DevTools e il debug, ma è stato adottato da Puppeteer per l'automazione. CDP comunica direttamente con i browser basati su Chromium tramite connessioni WebSocket, offrendo prestazioni più rapide e controllo a basso livello.

Tuttavia, funziona solo con i browser basati su Chromium e non è uno standard aperto. Inoltre, le API CDP sono relativamente complesse. In alcuni casi, lavorare con CDP non è ergonomico. Ad esempio, lavorare con iframe out-of-process richiede molto impegno.

Ad esempio, il clic su un elemento await coffee.click(); viene tradotto in una serie di comandi CDP.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

Quali sono i controlli di basso livello?

Quando è stato sviluppato WebDriver "classico", non era necessario un controllo a basso livello. Ma i tempi sono cambiati, il web è molto più capace ora e i test richiedono oggi azioni più granulari.

Poiché CDP è stato progettato per soddisfare tutte le esigenze di debug, supporta più controlli a basso livello rispetto a WebDriver "classico". È in grado di gestire funzionalità come:

• Acquisizione dei messaggi della console
• Intercettazione delle richieste di rete
• Simulazione della modalità del dispositivo
• Simulazione della geolocalizzazione
• E tanto altro.

Queste operazioni non erano possibili in WebDriver "classico" a causa della diversa architettura: WebDriver "classico" è basato su HTTP, il che rende complicato iscriversi e ascoltare gli eventi del browser. CDP, invece, è basato su WebSocket e supporta la messaggistica bidirezionale per impostazione predefinita.

Passaggi successivi: WebDriver BiDi

Ecco un riepilogo dei punti di forza di WebDriver "classico" e CDP:

WebDriver BiDi mira a combinare i migliori aspetti di WebDriver "classico" e CDP. Si tratta di un nuovo protocollo standard di automazione del browser attualmente in fase di sviluppo.

Scopri di più sul progetto WebDriver BiDi: come funziona, la visione e la procedura di standardizzazione.