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

Jecelyn Yeen

Maksim Sadym

La nascita dell'automazione dei test

Torniamo 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 di test cross-browser e multi-dispositivo.

Questi due progetti hanno unito le forze nel 2011 con il nome di Selenium WebDriver ed è diventato uno standard W3C nel 2018. In genere lo chiamiamo WebDriver o WebDriver "Classic".

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

L'ascesa di JavaScript

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

Approcci all'automazione

In generale, questi strumenti possono essere organizzati in due gruppi principali in base a come 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. Curiosità: anche la prima versione di Selenium ha utilizzato lo stesso approccio.
• Basso livello: strumenti che eseguono comandi remoti al di fuori del browser. Quando gli strumenti richiedono un controllo ancora maggiore, come l'apertura di più schede o la simulazione della modalità del dispositivo, è in questi casi che devono eseguire comandi remoti per controllare il browser tramite protocolli. I due protocolli di automazione principali sono WebDriver "Classic" e Chrome DevTools (CDP).

Nella prossima sezione, esamineremo i due protocolli per comprenderne i punti di forza e i limiti.

WebDriver versione classica e protocollo CDP (Chrome DevTools)

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

Sebbene offra un eccellente supporto tra browser 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 '{}'

Il protocollo CDP (Chrome DevTools) è stato invece progettato inizialmente per Chrome DevTools e per 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ù veloci e un controllo di 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, l'elaborazione di iframe out-of-process richiede un notevole 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 }
}

Cosa sono i controlli di basso livello?

Ai tempi in cui è stato sviluppato WebDriver "Classic", non c'era bisogno di un controllo di basso livello. Ma i tempi sono cambiati, ora il web è molto più efficace e oggi effettuare test richiede azioni più granulari.

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

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

Ciò non è stato possibile in WebDriver "Classic" a causa delle diverse architetture: WebDriver "Classic" è basato su HTTP, il che rende difficile iscriversi e ascoltare gli eventi del browser. CDP, d'altra parte, è basato su WebSocket e supporta la messaggistica bidirezionale per impostazione predefinita.

Passaggi successivi: WebDriver BiDi

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

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

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