Test end-to-end delle app Electron: oltre il supporto di Playwright per Electron

Questa guida è per gli sviluppatori e le persone del QA di un'app desktop Electron.Dice cosa rende diverso il test di un'app di questo tipo, fa un resoconto onesto dell'API Electron di Playwright, poi mostra un test end-to-end attraverso la pagina, la finestra di dialogo dei file nativa, un'esportazione e la sua notifica, eseguito a ogni build.

Cosa rende diverso il test di un'app Electron

Un'app Electron è due programmi che lavorano insieme.Il processo principale gira in Node.js: apre le finestre, gestisce il ciclo di vita dell'app, e chiede al sistema operativo tutto ciò che è nativo, come menu, finestre di dialogo e icone nell'area di notifica.Ogni finestra esegue poi un processo renderer, che è una pagina Chromium: HTML, CSS e JavaScript, come un sito web.

Per i test, questa divisione conta.Uno strumento fatto per i siti web vede la pagina e solo la pagina.Un utente vede tutto: la barra dei menu, la finestra di dialogo dei file di Windows che si apre su Apri, la notifica che dice che l'esportazione è completata, l'icona che resta nell'area di notifica dopo la chiusura della finestra.

Cosa copre l'API Electron di Playwright, e dove si ferma

Tra gli strumenti di test dell'interfaccia per Electron, Playwright è quello che la maggior parte dei team prova per primo, perché lo usa già per la propria app web.La sua classe Electron è documentata come supporto sperimentale, per Electron 21 e successivi.Il test avvia l'app dal suo script di ingresso, ottiene ogni finestra come una pagina Playwright, ed esegue codice nel processo principale con evaluate().

È un vero accesso all'interno dell'app.Ogni locator, clic e asserzione che Playwright offre su una pagina web funziona sul renderer, una seconda finestra arriva tramite l'evento window, ed evaluate() può leggere o modificare lo stato dell'app.Vedete la classe ElectronApplication per l'elenco completo.

Il limite è documentato con la stessa chiarezza.Le chiamate alle finestre di dialogo native come dialog.showOpenDialog non vengono intercettate, perché vanno dritte al sistema operativo, e la documentazione consiglia di sostituire quei metodi dal test con uno stub che restituisce il percorso del file desiderato.La vera finestra di dialogo non si apre mai, quindi non viene mai testata.Lo stesso vale per tutto il resto che il sistema operativo disegna fuori dalla pagina.

Fatti letti nella documentazione di Playwright il 6 novembre 2026.Playwright ed Electron sono marchi dei rispettivi proprietari; questa guida non è affiliata a essi né approvata da essi.

Un solo test end-to-end attraverso il renderer e la shell

Ecco come testare un'app Electron end-to-end in GUI Test Studio, con un'app di fatturazione come esempio: aprire un file tramite la finestra di dialogo nativa, modificare una riga, esportare un PDF, e controllare la notifica che dice che è fatto.

1. 1

   Registrare l'app, non la pagina

   In GUI Test Runner-Recorder, fate clic su Registra e scegliete Un'app.Selezionate la vostra app Electron, oppure cercate il suo eseguibile, e spuntate la casella che la avvia con il test e la chiude alla fine, così ogni esecuzione parte da un'app appena aperta.Poi usatela come farebbe un utente.

   

   Ingrandisci

2. 2

   Aprire un file tramite la vera finestra di dialogo

   Fate clic su Apri.Per la registrazione, la finestra di dialogo dei file di Windows è una finestra come le altre: digitate il percorso del file nel campo del nome file e premete Invio, ed entrambi vengono registrati come input reale.Prima del clic viene registrato un controllo della finestra di dialogo, così l'esecuzione attende che sia davvero aperta.

   Molte app Electron sono servite anche come pagina web.Per quella versione delle stesse schermate, il passaggio Carica file consegna il file alla pagina senza alcuna finestra di dialogo.

3. 3

   Modificare, esportare e leggere la notifica

   Cambiate una quantità, fate clic su Esporta.Quando compare la notifica, lasciatela visibile un momento prima di fermarvi: la registrazione annota ciò che è comparso, e il test ne riceve un controllo.

4. 4

   Dire cosa deve verificare il test

   Quando vi fermate, GUI Test Runner-Recorder chiede cosa deve verificare il test: gli elementi su cui avete fatto clic, i testi e ciò che è comparso sullo schermo.Lasciate attivi tutti e tre.Ogni passaggio diventa poi un blocco sulla timeline in GUI Test Studio, e nulla in essa nomina un processo.

I controlli che contano: testo, aspetto visivo, layout

Una registrazione dà al test i controlli che mirano i suoi clic.Quelli che vale la pena aggiungere a mano colgono ciò che un'app Electron rompe più spesso.

Ogni confronto ignora il rumore di rendering che due esecuzioni hanno sempre, una sfumatura più chiara qui, un bordo più morbido là, e coglie comunque le vere regressioni che una persona chiamerebbe un cambiamento: un'icona mancante, una parola cambiata, un pulsante del colore sbagliato.Vedete Asserzioni visive per sapere quanto è rigoroso ogni controllo.

Il report di affidabilità dice poi, per ogni controllo, se l'elemento è stato trovato e se ha l'aspetto registrato, con l'immagine attesa e quella trovata affiancate.Per un'app desktop i cui controlli Windows non sa descrivere, lo stesso approccio funziona solo a vista: vedete testare le app Windows senza albero di accessibilità.

Test automatici di Electron a ogni build

gtr-cli, l'esecutore da riga di comando, esegue il test esattamente come il pulsante Esegui test, e aggiunge ciò che serve a una pipeline: un codice di uscita, un file JUnit e ogni prova di un errore in un'unica cartella.

gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifacts

Il passaggio Esegui app all'inizio del test avvia la build in prova: puntatelo sull'eseguibile pacchettizzato prodotto dalla build, e lo stesso test controlla ogni versione che rilasciate.L'agente di build ha bisogno di una sessione desktop di Windows con l'utente connesso e sbloccata, perché l'app disegna su uno schermo reale.La guida CI/CD lo configura per TeamCity, Jenkins, GitHub Actions, GitLab e Azure DevOps.

Ingrandisci

Una cosa qui non si applica.Browser e dispositivi di GUI Test Studio creano versioni di un test web per Chrome, Edge, Firefox e telefoni emulati, come spiega il test cross-browser.Un'app Electron porta con sé il proprio Chromium, quindi c'è un solo browser da testare, e le versioni che contano sono le vostre build.

Quando l'API Electron di Playwright resta lo strumento giusto

Una guida onesta dice dove vince l'altro strumento, e qui vince.L'API Electron di Playwright è la scelta giusta per i test a livello di codice del processo principale: evaluate() legge direttamente lo stato dell'app, una finestra di dialogo sostituita da uno stub rende un test della gestione dei file veloce ed esatto, e nulla di tutto ciò ha bisogno di uno schermo.Un team che scrive già test Playwright per la propria app web mantiene nel renderer i propri locator e le proprie abitudini, ed esegue quei test in pochi secondi a ogni pull request.

I due non sono rivali.Tenete Playwright per il renderer e il processo principale, e un test dello schermo per il percorso che un utente compie attraverso la shell: la vera finestra di dialogo, il vero menu, la vera notifica, sulla vera build.Ognuno coglie ciò che l'altro non può vedere.

Punti chiave

• 1Un'app Electron è una pagina più una shell: il processo principale possiede finestre di dialogo, menu, area di notifica e notifiche, e un utente le incontra tutte.
• 2L'API Electron di Playwright raggiunge la pagina e il processo principale dal codice, e la sua stessa documentazione dice che le finestre di dialogo native non vengono intercettate.
• 3GUI Test Studio testa l'app come la vede l'utente: l'intero schermo registrato, la vera finestra di dialogo dei file pilotata come qualsiasi finestra, nessuna build di test e nessun plugin.
• 4Le asserzioni testuali, visive e di layout colgono ciò che si rompe: un totale sbagliato, un'icona mancante, una voce di menu disattivata, una finestra dietro un'altra.
• 5Lo stesso test viene eseguito a ogni build con gtr-cli, con un file JUnit per la pipeline; Browser e dispositivi sono per le pagine web, qui le versioni sono le vostre build.

Domande

Electron, Playwright, Chromium, Node.js, Windows, TeamCity, Jenkins, GitHub, GitLab e Azure DevOps sono marchi dei rispettivi proprietari.