How Guru’s Engineers Use Cypress for Better Burn Testing
Hai bisogno di un modo migliore per gestire il burn testing? Due dei nostri ingegneri front end hanno trovato un modo per utilizzare Cypress per migliorare il modo in cui gestiscono la QA.
Siamo tutti dedicati alla condivisione della conoscenza in Guru, e quando scopriamo qualcosa di nuovo e utile, vogliamo che il mondo lo sappia! Il nostro team di ingegneri utilizza Cypress nei loro processi di test e QA. Hanno scoperto un nuovo modo per eseguire test di burn migliori, e vogliono condividere il loro nuovo e migliorato processo con altri ingegneri e tester.
Nell'ultimo anno, ci siamo concentrati sull'aumento della copertura dei nostri test, in particolare, i test end-to-end che garantiscono che diverse parti del nostro prodotto funzionino correttamente mentre aggiorniamo il codice. Per questo tipo di test, utilizziamo uno strumento chiamato Cypress che simula il comportamento degli utenti con la nostra app web e l'estensione di Google Chrome. Questa suite di test viene eseguita ad ogni pull request per garantire che il nuovo codice non rompa nulla nella nostra interfaccia utente. Vogliamo anche bloccare le release se la nostra suite Cypress fallisce nel nostro branch di produzione.
Cosa cerchiamo nei test tradizionali
Un problema con cui abbiamo dovuto confrontarci è vedere alcuni dei nostri test fallire, ma non per motivi legati all'interfaccia utente o al codice. Quindi, come ci aiuta Cypress in questi casi? Abbiamo Cypress che agisce come un utente il cui comportamento possiamo definire. Ci sono diverse variabili che potrebbero portare Cypress a dirci che c'è un fallimento, ma dalla prospettiva di un utente, nulla sembra sbagliato.
Ad esempio, potrebbe esserci un test che dice: “Vai in questa parte dell'app web > Aggiungi una nuova scheda Guru > Aspettati di vedere uno stato post-creazione”. Se lo stato di caricamento per la creazione di una scheda si fermasse per un millisecondo di troppo e Cypress cominciasse a cercare lo stato post-creazione prima che sia pronto, questo test potrebbe fallire (però, la maggior parte delle volte, questo test passerà). Se passa una volta su una pull request, siamo in grado di unire un codice che a volte potrebbe essere instabile. Ma non sapremo se lo è; un test superato non garantisce che il codice sia corretto.
Questo tipo di situazione diminuisce l'affidabilità della nostra copertura dei test. Di conseguenza, quando si presenta un fallimento di test nella nostra pipeline di deployment, dobbiamo verificare se è un problema con l'interfaccia utente o con il test. Per risolvere questo problema abbiamo iniziato a pensare a modi in cui potremmo rilevare se un test potrebbe essere instabile prima di passare al nostro branch di codice di produzione.
Come il burn testing aiuta
Entriamo nel burn testing. Il burn testing è un processo usato per testare qualcosa in condizioni più rigorose o estreme. A volte viene anche chiamato stress testing o load testing, a seconda del metodo o dell'area specifica testata.
In Guru, utilizziamo il burn testing come parte della nostra suite Cypress per tutti i nuovi test o per i test modificati che vengono aggiunti al nostro codice. Prima che questi test possano essere fusi, li eseguiamo più volte di seguito e devono tutti passare per poter passare al passaggio successivo nella nostra pipeline di costruzione CircleCI.
Questo passaggio avviene immediatamente prima di eseguire l'intera suite di test Cypress. Il vantaggio di questo ordine è che se il nostro passo di burn testing produce un fallimento, possiamo contrassegnare l'intero controllo come un fallimento in anticipo. Saltare il resto della suite ci consente di risparmiare tempo e ridurre il numero di cicli necessari per garantire che i test recentemente introdotti siano affidabili e tolleranti ai guasti come abbiamo bisogno.
Per trovare i file che stiamo cercando, utilizziamo git diff sul branch attuale e forniamo l'output come parametro a uno strumento chiamato cypress-repeat che ci consente di eseguire quei test qualsiasi numero specificato di volte, aggiungendo di fatto il burn testing come un passaggio nella nostra suite di test end-to-end.
Il risultato
Aggiungere questa modifica ai nostri piani di test ha prodotto risultati piuttosto solidi. Per noi, aggiungere il burn testing può ridurre il tempo necessario per individuare test non affidabili fino a 30 minuti. Migliora anche il tempo di risposta per aggiungere nuove funzionalità. Poiché i test recentemente aggiunti vengono ora eseguiti per primi, ci consentono di verificare la stabilità prima di passare al resto del processo di costruzione.
In generale, il nostro continuo impegno a rendere i nostri processi di test più efficienti e robusti aumenta la fiducia dell'intero team di ingegneria nel rilasciare nuove funzionalità rapidamente. Stiamo correggendo i bug più velocemente e facilitando il lavoro su tutti i nostri codici. Speriamo che questo post aiuti altri utenti di Cypress a creare test migliori e intere squadre a lavorare in modo più efficiente.
Siamo tutti dedicati alla condivisione della conoscenza in Guru, e quando scopriamo qualcosa di nuovo e utile, vogliamo che il mondo lo sappia! Il nostro team di ingegneri utilizza Cypress nei loro processi di test e QA. Hanno scoperto un nuovo modo per eseguire test di burn migliori, e vogliono condividere il loro nuovo e migliorato processo con altri ingegneri e tester.
Nell'ultimo anno, ci siamo concentrati sull'aumento della copertura dei nostri test, in particolare, i test end-to-end che garantiscono che diverse parti del nostro prodotto funzionino correttamente mentre aggiorniamo il codice. Per questo tipo di test, utilizziamo uno strumento chiamato Cypress che simula il comportamento degli utenti con la nostra app web e l'estensione di Google Chrome. Questa suite di test viene eseguita ad ogni pull request per garantire che il nuovo codice non rompa nulla nella nostra interfaccia utente. Vogliamo anche bloccare le release se la nostra suite Cypress fallisce nel nostro branch di produzione.
Cosa cerchiamo nei test tradizionali
Un problema con cui abbiamo dovuto confrontarci è vedere alcuni dei nostri test fallire, ma non per motivi legati all'interfaccia utente o al codice. Quindi, come ci aiuta Cypress in questi casi? Abbiamo Cypress che agisce come un utente il cui comportamento possiamo definire. Ci sono diverse variabili che potrebbero portare Cypress a dirci che c'è un fallimento, ma dalla prospettiva di un utente, nulla sembra sbagliato.
Ad esempio, potrebbe esserci un test che dice: “Vai in questa parte dell'app web > Aggiungi una nuova scheda Guru > Aspettati di vedere uno stato post-creazione”. Se lo stato di caricamento per la creazione di una scheda si fermasse per un millisecondo di troppo e Cypress cominciasse a cercare lo stato post-creazione prima che sia pronto, questo test potrebbe fallire (però, la maggior parte delle volte, questo test passerà). Se passa una volta su una pull request, siamo in grado di unire un codice che a volte potrebbe essere instabile. Ma non sapremo se lo è; un test superato non garantisce che il codice sia corretto.
Questo tipo di situazione diminuisce l'affidabilità della nostra copertura dei test. Di conseguenza, quando si presenta un fallimento di test nella nostra pipeline di deployment, dobbiamo verificare se è un problema con l'interfaccia utente o con il test. Per risolvere questo problema abbiamo iniziato a pensare a modi in cui potremmo rilevare se un test potrebbe essere instabile prima di passare al nostro branch di codice di produzione.
Come il burn testing aiuta
Entriamo nel burn testing. Il burn testing è un processo usato per testare qualcosa in condizioni più rigorose o estreme. A volte viene anche chiamato stress testing o load testing, a seconda del metodo o dell'area specifica testata.
In Guru, utilizziamo il burn testing come parte della nostra suite Cypress per tutti i nuovi test o per i test modificati che vengono aggiunti al nostro codice. Prima che questi test possano essere fusi, li eseguiamo più volte di seguito e devono tutti passare per poter passare al passaggio successivo nella nostra pipeline di costruzione CircleCI.
Questo passaggio avviene immediatamente prima di eseguire l'intera suite di test Cypress. Il vantaggio di questo ordine è che se il nostro passo di burn testing produce un fallimento, possiamo contrassegnare l'intero controllo come un fallimento in anticipo. Saltare il resto della suite ci consente di risparmiare tempo e ridurre il numero di cicli necessari per garantire che i test recentemente introdotti siano affidabili e tolleranti ai guasti come abbiamo bisogno.
Per trovare i file che stiamo cercando, utilizziamo git diff sul branch attuale e forniamo l'output come parametro a uno strumento chiamato cypress-repeat che ci consente di eseguire quei test qualsiasi numero specificato di volte, aggiungendo di fatto il burn testing come un passaggio nella nostra suite di test end-to-end.
Il risultato
Aggiungere questa modifica ai nostri piani di test ha prodotto risultati piuttosto solidi. Per noi, aggiungere il burn testing può ridurre il tempo necessario per individuare test non affidabili fino a 30 minuti. Migliora anche il tempo di risposta per aggiungere nuove funzionalità. Poiché i test recentemente aggiunti vengono ora eseguiti per primi, ci consentono di verificare la stabilità prima di passare al resto del processo di costruzione.
In generale, il nostro continuo impegno a rendere i nostri processi di test più efficienti e robusti aumenta la fiducia dell'intero team di ingegneria nel rilasciare nuove funzionalità rapidamente. Stiamo correggendo i bug più velocemente e facilitando il lavoro su tutti i nostri codici. Speriamo che questo post aiuti altri utenti di Cypress a creare test migliori e intere squadre a lavorare in modo più efficiente.
Scopri il potere della piattaforma Guru in prima persona - fai il nostro tour interattivo del prodotto
