{"id":1651,"date":"2021-12-13T11:32:00","date_gmt":"2021-12-13T10:32:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/test-automation-selenium-cypress-playwright-2021\/"},"modified":"2021-12-13T11:32:00","modified_gmt":"2021-12-13T10:32:00","slug":"test-automation-selenium-cypress-playwright-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/test-automation-selenium-cypress-playwright-2021\/","title":{"rendered":"Test automation 2021: Selenium, Cypress, Playwright per PMI"},"content":{"rendered":"
\n

TL;DR \u2014 In sintesi:<\/strong> Nel 2021 il test automation E2E non \u00e8 pi\u00f9 un “nice to have”: per una software house o PMI con team superiore ai 5 sviluppatori il manual testing diventa il principale bottleneck di rilascio. I tre framework dominanti sono Selenium WebDriver<\/strong> (rilascio 4.0 il 13 ottobre 2021, ora W3C standard), Cypress<\/strong> (versione 9.0 da luglio 2021) e Playwright<\/strong> (Microsoft, versione 1.16 di novembre 2021). In questo articolo confrontiamo architettura, costi e produttivit\u00e0, con un caso reale di migrazione da Selenium a Playwright che ha portato la suite di test da 18 min a 4 min e ridotto la flakiness dell’82%.<\/p>\n<\/div>\n

Test automation 2021: Selenium, Cypress, Playwright per PMI<\/h1>\n

Quanto tempo impiega oggi il tuo team a validare manualmente una release? Tre ore? Una giornata intera? Per molte PMI software italiane il QA manuale resta ancora la norma \u2014 fino al momento in cui il backlog di feature cresce, il numero di sviluppatori supera i 5-6 e il tempo di regression testing si moltiplica con ogni nuovo modulo. A quel punto il test automation non \u00e8 pi\u00f9 una scelta tecnologica ma una questione di sopravvivenza<\/strong> sul mercato.<\/p>\n

Il 2021 \u00e8 stato un anno spartiacque per l’ecosistema del testing. Il 13 ottobre 2021 \u00e8 uscito Selenium 4.0<\/strong>, primo rilascio major dopo cinque anni di sviluppo, allineato finalmente allo standard W3C WebDriver. Cypress<\/strong>, lanciato nel 2017, ha raggiunto la versione 9.0 a luglio 2021 con supporto stabile a Firefox e session API. Ma il vero scossone arriva da Redmond: Playwright<\/strong>, rilasciato da Microsoft nel 2020 e cresciuto rapidamente, ha pubblicato la 1.16 a novembre 2021 con auto-wait nativo, multi-browser cross-platform e supporto a JavaScript, TypeScript, Python, Java e .NET.<\/p>\n

In questa guida operativa analizziamo i framework dominanti, i loro casi d’uso ideali, gli strumenti complementari (visual regression, API testing, performance) e come strutturare un piano di adozione in 60 giorni per una PMI italiana. Vediamo prima i fondamentali concettuali, poi entriamo nei tool e infine in un caso concreto di migrazione.<\/p>\n

Test pyramid di Mike Cohn: la base teorica<\/h2>\n

Prima di scegliere un framework occorre capire quale livello di test stiamo automatizzando. Il modello di riferimento resta la Test Pyramid<\/strong> introdotta da Mike Cohn nel suo libro “Succeeding with Agile” del 2009 e poi resa popolare da Martin Fowler. La piramide divide i test in tre strati:<\/p>\n

    \n
  • Unit test (base, ~70%)<\/strong>: testano singole funzioni o classi in isolamento. Veloci (millisecondi), economici da scrivere e mantenere. Tool: Jest<\/strong>, Mocha<\/strong> + Chai<\/strong> per JavaScript, PyTest<\/strong> per Python, JUnit + Mockito<\/strong> per Java, PHPUnit per PHP.<\/li>\n
  • Integration test (~20%)<\/strong>: verificano l’interazione tra moduli, chiamate API, query database. Pi\u00f9 lenti (centinaia di ms), ma coprono comportamenti che gli unit test non vedono.<\/li>\n
  • End-to-End (E2E, ~10%)<\/strong>: simulano l’utente reale che usa l’applicazione tramite browser. Lenti (secondi-minuti), costosi da mantenere, ma sono gli unici a validare il flusso completo.<\/li>\n<\/ul>\n

    Il problema pi\u00f9 comune che vediamo nelle PMI italiane \u00e8 la “piramide invertita”<\/strong>: pochi unit test, molti test E2E. Risultato: suite che impiegano un’ora a girare, flakiness alta, ogni piccolo refactoring rompe decine di scenari. La regola pratica: se hai 100 test totali, almeno 70 devono essere unit, 20 integration, 10 E2E. Selenium, Cypress e Playwright lavorano principalmente sull’apice della piramide, ma la qualit\u00e0 della tua suite dipende soprattutto da quanto \u00e8 solida la base.<\/p>\n

    \"Terminal<\/p>\n

    Cos’\u00e8 il test automation E2E e perch\u00e9 serve davvero<\/h2>\n

    Un test E2E (End-to-End) \u00e8 uno script che simula un utente reale<\/strong>: apre il browser, clicca link, compila form, attende risposte AJAX, verifica che i dati salvati appaiano correttamente nella UI. \u00c8 l’unico tipo di test che convalida il sistema “as a whole”: frontend + backend + database + servizi esterni.<\/p>\n

    Per una PMI software i benefici concreti sono tre. Primo: riduzione del regression testing<\/strong> da giorni a minuti. Secondo: confidenza nel deploy continuo (CI\/CD) \u2014 senza E2E automatizzati il “deploy del venerd\u00ec” resta un terno al lotto. Terzo: documentazione vivente. Uno script Cypress ben scritto descrive il comportamento atteso meglio di qualsiasi pagina Confluence.<\/p>\n

    Lo svantaggio principale dei test E2E \u00e8 la fragilit\u00e0<\/strong>: dipendono dal DOM, dalla rete, dai tempi di rendering. Un test che funziona in locale pu\u00f2 fallire sporadicamente in CI (“flaky test”) creando rumore e perdita di fiducia. La scelta del framework giusto incide direttamente su questo aspetto.<\/p>\n

    Selenium WebDriver: il veterano (e Selenium 4)<\/h2>\n

    Nato nel 2004 da un progetto interno di ThoughtWorks come “JavaScriptTestRunner”, Selenium<\/strong> \u00e8 il framework di test automation pi\u00f9 longevo e diffuso al mondo. La versione WebDriver, sviluppata da Simon Stewart a partire dal 2007, \u00e8 oggi il de-facto standard per pilotare browser via codice.<\/p>\n

    Il 13 ottobre 2021 \u00e8 uscito Selenium 4.0<\/strong>, primo major release dopo 5 anni di lavoro. Le novit\u00e0 chiave:<\/p>\n

      \n
    • W3C WebDriver Recommendation<\/strong>: protocollo standardizzato dal W3C nel 2018 e ora pienamente adottato. Niente pi\u00f9 JSON Wire Protocol legacy.<\/li>\n
    • Selenium Grid 4<\/strong>: architettura rifatta con Docker support nativo, observability (tracing OpenTelemetry), e UI pi\u00f9 moderna.<\/li>\n
    • Relative Locators<\/strong>: API tipo above(), below(), near() per selezionare elementi in base alla posizione visuale.<\/li>\n
    • Chrome DevTools Protocol (CDP)<\/strong>: accesso a network throttling, geolocation, console log.<\/li>\n<\/ul>\n

      I punti di forza di Selenium WebDriver<\/strong> restano la maturit\u00e0<\/strong> (community immensa, decine di migliaia di articoli, libri, corsi), il multi-language<\/strong> (Java, Python, C#, Ruby, JavaScript, Kotlin), e l’integrazione con tutti<\/em> i browser farm cloud (BrowserStack<\/strong>, Sauce Labs<\/strong>, LambdaTest<\/strong>). Selenium \u00e8 la scelta giusta quando hai sviluppatori back-end Java\/.NET, devi testare browser legacy (IE 11 ancora richiesto da clienti enterprise) o hai vincoli di compliance.<\/p>\n

      Lato negativo: architettura WebDriver “out-of-process” (comandi inviati via HTTP REST al driver) introduce latenza, no auto-wait nativo (servono WebDriverWait + ExpectedConditions espliciti), e debugging meno comodo rispetto ai framework moderni.<\/p>\n

      Cypress: la dev experience friendly<\/h2>\n

      Lanciato nel 2017 dalla startup californiana Cypress.io, Cypress<\/strong> ha cambiato le regole del gioco con un’architettura radicalmente diversa: invece di pilotare il browser dall’esterno via protocollo HTTP, Cypress gira dentro il browser<\/strong> con il test e l’applicazione nello stesso event loop. Questo elimina molti problemi di sincronizzazione tipici di Selenium.<\/p>\n

      Caratteristiche distintive:<\/p>\n

        \n
      • Time Travel Debugger<\/strong>: ogni comando crea uno snapshot del DOM. Puoi tornare indietro nel tempo e ispezionare lo stato esatto del test in qualsiasi step.<\/li>\n
      • Auto-wait nativo<\/strong>: Cypress attende automaticamente che gli elementi siano visibili, abilitati, attached al DOM prima di interagire.<\/li>\n
      • Network stubbing nativo<\/strong>: intercetti chiamate XHR\/fetch con cy.intercept() senza tool esterni.<\/li>\n
      • Dashboard cloud<\/strong> (a pagamento da ~75$\/mese<\/strong>): video recording, parallel execution, analytics.<\/li>\n<\/ul>\n

        La versione Cypress 9.0<\/strong> di luglio 2021 ha portato supporto stabile a Firefox (precedentemente beta) e session API (cy.session()) per cache di login tra test. La community \u00e8 in forte crescita: secondo lo State of JS 2021, Cypress<\/strong> \u00e8 il framework di testing E2E pi\u00f9 utilizzato dagli sviluppatori JavaScript con il 38%<\/strong> di adoption, superando Selenium tra chi lavora su frontend SPA.<\/p>\n

        Limiti: solo JavaScript\/TypeScript (niente Python, Java), supporto multi-tab limitato, niente Safari (al 2021), no controllo browser nativo come click su dialog del sistema operativo, esecuzione sequenziale su singolo browser per default.<\/p>\n

        Playwright: la sfida di Microsoft<\/h2>\n

        Annunciato a gennaio 2020 da Microsoft (autori in gran parte ex-team Puppeteer di Google migrati a Redmond), Playwright<\/strong> ha avuto un’evoluzione fulminea. La versione 1.16<\/strong> rilasciata a novembre 2021 lo posiziona come alternativa moderna a Selenium con un’esperienza developer simile a Cypress ma senza i suoi limiti.<\/p>\n

        Punti di forza chiave:<\/p>\n

          \n
        • Multi-browser<\/strong>: Chromium, Firefox e WebKit (motore Safari) tutti gestiti con un’unica API. Cross-browser reale, anche su Linux\/CI.<\/li>\n
        • Multi-language<\/strong>: bindings ufficiali per JavaScript\/TypeScript, Python, Java, .NET. Non solo Node.js come Cypress<\/strong>.<\/li>\n
        • Auto-wait built-in<\/strong>: ogni azione (click, fill, selectOption) attende automaticamente che l’elemento sia “actionable”.<\/li>\n
        • Parallel execution nativa<\/strong>: la 1.10 (marzo 2021) ha introdotto il test runner ufficiale con parallel workers out-of-the-box.<\/li>\n
        • Trace Viewer<\/strong>: GUI che mostra timeline, network, console, screenshot per ogni step. Game-changer per debug.<\/li>\n
        • Multi-context<\/strong>: gestisce pi\u00f9 tab, popup, iframe e contesti di sessione paralleli (utile per testare chat, multi-user).<\/li>\n<\/ul>\n

          Lo svantaggio \u00e8 una community ancora pi\u00f9 piccola di Selenium<\/strong> e meno integrazione con tool legacy. Ma per nuovi progetti, soprattutto su stack moderno (React, Vue, Angular, Next.js), Playwright<\/strong> \u00e8 oggi la scelta tecnicamente pi\u00f9 solida.<\/p>\n

          Selenium vs Cypress vs Playwright: tabella comparativa<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
          Criterio<\/th>\nSelenium 4<\/th>\nCypress 9<\/th>\nPlaywright 1.16<\/th>\n<\/tr>\n<\/thead>\n
          Architettura<\/td>\nWebDriver (out-of-process)<\/td>\nIn-browser (in-process)<\/td>\nCDP-based (out-of-process, async)<\/td>\n<\/tr>\n
          Browser<\/td>\nChrome, Firefox, Safari, Edge, IE11<\/td>\nChrome, Edge, Firefox, Electron<\/td>\nChromium, Firefox, WebKit<\/td>\n<\/tr>\n
          Linguaggi<\/td>\nJava, Python, C#, JS, Ruby, Kotlin<\/td>\nJS\/TS<\/td>\nJS\/TS, Python, Java, .NET<\/td>\n<\/tr>\n
          Auto-wait<\/td>\nManuale (WebDriverWait)<\/td>\nS\u00ec, nativo<\/td>\nS\u00ec, nativo<\/td>\n<\/tr>\n
          Parallel locale<\/td>\nS\u00ec (Grid)<\/td>\nNo (solo dashboard a pagamento)<\/td>\nS\u00ec, nativo<\/td>\n<\/tr>\n
          Network stub<\/td>\nLimitato (CDP in 4)<\/td>\nNativo (cy.intercept)<\/td>\nNativo (page.route)<\/td>\n<\/tr>\n
          Multi-tab<\/td>\nS\u00ec<\/td>\nWorkaround<\/td>\nS\u00ec, nativo<\/td>\n<\/tr>\n
          Pricing<\/td>\nOSS gratis<\/td>\nOSS + Dashboard cloud (~75$\/mese<\/strong>)<\/td>\nOSS gratis<\/td>\n<\/tr>\n
          Community 2021<\/td>\nEnorme (15+ anni)<\/td>\nGrande, in crescita<\/td>\nMedia, in forte crescita<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          \"Cross<\/p>\n

          TestCafe: l’alternativa open source di DevExpress<\/h2>\n

          Tra le alternative meno note ma valide segnaliamo TestCafe<\/strong>, sviluppato da DevExpress e reso open source nel 2016. \u00c8 un framework Node.js che non richiede driver esterni: inietta uno script nelle pagine, intercetta richieste via proxy e supporta tutti i browser moderni inclusi i dispositivi mobile remoti.<\/p>\n

          Punti di forza: zero configuration (installi via npm e parti), supporto a TypeScript nativo, ottimo per team JavaScript che non vogliono la lock-in del dashboard Cypress<\/strong>. Per il 2021 resta una nicchia ma \u00e8 una scelta solida per progetti che cercano un’alternativa a costo zero al cloud di Cypress.<\/p>\n

          Mobile testing: Appium e Detox<\/h2>\n

          Per applicazioni mobile native o ibride (React Native, Flutter, Cordova) i framework E2E browser-based non bastano. I due tool dominanti nel 2021 sono:<\/p>\n

            \n
          • Appium<\/strong>: framework open source nato nel 2012, basato su WebDriver protocol. Nel 2021 la versione mainstream \u00e8 1.x; la 2.0 alpha \u00e8 in sviluppo. Funziona con iOS, Android, anche app desktop (Windows, Mac). Linguaggi: tutti quelli supportati da Selenium<\/strong>. Lo svantaggio \u00e8 la curva di apprendimento e i tempi di esecuzione.<\/li>\n
          • Detox<\/strong>: sviluppato da Wix, specifico per React Native. Architettura “grey-box”: il framework ha visibilit\u00e0 interna sull’app e pu\u00f2 sincronizzarsi con il render loop. Risultato: test molto pi\u00f9 veloci e affidabili di Appium per progetti React Native, ma vincolato a quello stack.<\/li>\n<\/ul>\n

            Visual regression testing: Percy, Chromatic, Applitools, BackstopJS<\/h2>\n

            I test E2E classici verificano che il bottone esista e sia cliccabile, ma non che sia bello<\/strong>. Un cambio di CSS pu\u00f2 rompere il layout senza far fallire alcun test. Per questo serve il visual regression testing:<\/p>\n