Vediamo chi mi batte: ieri finalmente abbiamo finito di parallelizzare un grosso è vecchio test dopo una serie di modifiche alla nostra suite di test di non regressione automatici. Ora ogni modifica, che sia di una label del frontend o di un refactoring degli eventi di backend, fa girare tutti i 120 test su un massimo di 50 browser (il limite di aws) in un totale di 4 minuti.
Dai ditemi che fate di meglio…
Che necessita' specifica hai di far girare i test su 50 browser diversi?
Io uso https://playwright.dev/ ho una test suite che faccio andare solo su chromium viewport desktop, ma volendo si aggiunge safari e la viewport mobile per un totale di 4 combinazioni e hai coperto 90% del mercato
Io uso https://playwright.dev/ ho una test suite che faccio andare solo su chromium viewport desktop, ma volendo si aggiunge safari e la viewport mobile per un totale di 4 combinazioni e hai coperto 90% del mercato
gira su 50 browsers nel senso che per far girare 120 test in 4 minuti (oggi siamo a 3 minuti e 31 secondi in media per essere precisi), devono girare più sessioni contemporaneamente. Dato che vogliamo avere tutti i test in completo isolamento, più o meno in contemporanea abbiamo una cinquantina di browser (in altrettante macchine) che fanno i test contemporaneamente, sotto aws usa selenium grid per il cluster di macchine.
Playwright è il client che implementa lo stesso protocollo di selenium. quindi tu virtualizzi multiple macchine con altrettanti browsers ma sulla stessa istanza server? ho capito bene? Quanti test? tempistiche? Sono curioso!
Playwright è il client che implementa lo stesso protocollo di selenium. quindi tu virtualizzi multiple macchine con altrettanti browsers ma sulla stessa istanza server? ho capito bene? Quanti test? tempistiche? Sono curioso!
Il nostro prodotto e' probabilmente molto piu' semplice quindi noi usiamo GitLab CI/CD, in passato ho lavorato con delle pipelines costruite su Jenkins invece.
Quando pusho del codice, in determinate situazioni, parte un GitLab worker (un container) che si basa sulla base image che fornisce ufficialmente Microsoft che ha dentro tutto quel che serve per node + playwright + diversi browser che vuoi usare.
https://playwright.dev/docs/ci#gitlab-ci
A quel punto puoi decidere se fare andare test in parallelo/seriale e quanti workers allocare, dove ogni worker e' un processo separato e di default usa meta' dei CPU core a meno che tu non specifichi un valore
https://playwright.dev/docs/api/class-testconfig#test-config-workers
I miei test nello specifico purtroppo devono andare in modo seriale xke ho una situazione dove devo verificare una serie di operazioni consecutive dove un utente invita altri utenti a collaborare e hanno permessi diversi.
Le uniche ottimizzazioni che faccio sono attorno al signup/login, dove mi posso salvare lo "stato" del browser per una determinata sessione dell'utente (cookies, localstorage, sessionstorage) cosi che poi posso riprendere da li senza ogni volta dover fare login partendo da capo.
Quando pusho del codice, in determinate situazioni, parte un GitLab worker (un container) che si basa sulla base image che fornisce ufficialmente Microsoft che ha dentro tutto quel che serve per node + playwright + diversi browser che vuoi usare.
https://playwright.dev/docs/ci#gitlab-ci
A quel punto puoi decidere se fare andare test in parallelo/seriale e quanti workers allocare, dove ogni worker e' un processo separato e di default usa meta' dei CPU core a meno che tu non specifichi un valore
https://playwright.dev/docs/api/class-testconfig#test-config-workers
I miei test nello specifico purtroppo devono andare in modo seriale xke ho una situazione dove devo verificare una serie di operazioni consecutive dove un utente invita altri utenti a collaborare e hanno permessi diversi.
Le uniche ottimizzazioni che faccio sono attorno al signup/login, dove mi posso salvare lo "stato" del browser per una determinata sessione dell'utente (cookies, localstorage, sessionstorage) cosi che poi posso riprendere da li senza ogni volta dover fare login partendo da capo.
Noi abbiamo deciso di prioritizzare la velocità sugli altri aspetti, quindi testiamo ogni cosa solo una volta con la UI, tutte le altre volte instrumentiamo attraverso chiamate alle nostre api, e dato che mocchiamo anche lintero provider degli utenti, possiamo testare le permutazioni più importanti di ruoli/configurazioni alla velocità della luce, senza nessuna hot cache.
Ma quanto dura l’intera suite? È uno step obbligatorio ad ogni merge request?
Ma quanto dura l’intera suite? È uno step obbligatorio ad ogni merge request?
Dura circa 5 minuti la suite e un altro paio di minuti scarsi che il container si prepara, pulla l'immagine, la cache etc.
Abbiamo due env principali: qa e prod associati rispettivamente a due branch canary e main, l'unico momento dove eseguiamo i test e2e e' quando vuoi fare un merge da canary a main, ovvero da qa a prod.
Il resto delle merge request per qualsiasi altro branch che va a finire in canary (qa) non ci sono e2e test ma solo linting/type checks.
I mock sono uno strumento molto potente ma attenzione che quando introduci un mock non e' piu' un test e2e a mio avviso
Hehe oramai ho un bel po di esperienza in merito, non lavorerò mai più per un’azienda che non fa mock delle terze parti, è come lavorare all’età della pietra.
Principalmente perché ho bisogno istantaneo di feedback e deve essere riproducibile al 100%. Non abbiamo QA e tempo da perdere a capire dove stanno gli errori per via di terze parti che sono lente e buggate, ma anche no grazie. Ti assicuro che è un altro mondo.
Casomai ci fossero dubbi, sono in un progetto dove stiamo al termine di una serie di cose infinite: camion che ci mandano dati, R&D che manda metriche sulla produzione di pezzi nuovi, as400 che fa as400, IA che fa previsioni. E comunque gliene diamo di mock come se non ci fosse un domani.
E andiamo direttamente in produzione. Niente canary ne release management. Uptime a 99.9 (faremo presto meglio spero).
Principalmente perché ho bisogno istantaneo di feedback e deve essere riproducibile al 100%. Non abbiamo QA e tempo da perdere a capire dove stanno gli errori per via di terze parti che sono lente e buggate, ma anche no grazie. Ti assicuro che è un altro mondo.
Casomai ci fossero dubbi, sono in un progetto dove stiamo al termine di una serie di cose infinite: camion che ci mandano dati, R&D che manda metriche sulla produzione di pezzi nuovi, as400 che fa as400, IA che fa previsioni. E comunque gliene diamo di mock come se non ci fosse un domani.
E andiamo direttamente in produzione. Niente canary ne release management. Uptime a 99.9 (faremo presto meglio spero).
Ho letto dopo: 5 minuti è ottimo!
Si forse mi sono espresso male sul mocking, ci sono una marea di situazione e contesti diversi.
Quando dico che mocking e' anti-pattern intendevo fare mocking di inter-dipendenze tra servizi nostri.
Servizi esterni ne usiamo molto pochi, nel prodotto che gestisco io solo Stripe per i pagamenti e tutto sommato mi e' piu semplice far girare un test e2e che fare mocking dato che si tratta di aggiungere una carta fittizia e fare un pagamento nel loro ambiente sandbox, permettendomi di testare al meglio (ovvero come un utente userebbe il prodotto) e verificare che tutto il flow funziona non tanto lato Stripe ma lato nostro.
Detto questo, ci sono stati casi anche molto gravi dove non venivano testate le dipendenze esterne third party e sono successi disastri.
Se uno ha la possibilita' magari non a tutte le merge request ma saltuariamente o con un cron di far un test sulle dipendenze esterne sicuramente male non fa e ti permette di acchiappare il prima possibile se ci sono problemi su cose che non dipendono da te piuttosto che aspettare che si rompa necessariamente qualcosa in produzione.
Fidarsi e' bene, non fidarsi e' meglio.
Poi again, non so cosa fai di preciso e le casistiche sono infinite
Una cosa carina che abbiamo fatto lato testing invece e' sulla parte mobile.
tl;dr:il nostro prodotto e' un API che ti permette di verificare numeri di telefono senza dover mandare l'SMS col codice da inserire come fanno tutti al momento ma in modo diretto e piu' sicuro.
Abbiamo una mobile app di demo molto semplice fatta con React Native e vogliamo poter testare che tutti gli operatori che supportiamo continuino a funzionare, ed e' una cosa che ad oggi tranne pagare sistemi estremamente costosi e macchinosi, non si puo' fare xke richiede dei simulatori che hanno una SIM card di un determinato operatore, nessun servizio tipo AWS device farm e simili ti offre questa possibilita'.
Quindi sfruttiamo le silent push notification per fare un trigger di questa verifica (sono solo un paio di chiamate HTTP, consumo pari a zero) a tutti gli utenti che hanno scaricato la nostra app di demo e fanno opt-in in cambio di crediti, cosi durante il giorno random triggheriamo dei test su diversi operatori in diversi paesi del mondo su device di persone che hanno dato l'opt-in.
Ah ho capito il tuo caso… si anche io quando facevo integrazioni con psp dovevo tener su monitoring pesanti, sopratutto perché non c’era la semplicità di un sistema pub sub dove potevi vedere se tutti i consumer erano su, che è il mio maggior tipo di integrazione al momento.
Comunque dagli un’altra chances al mock e2e, niente ti vieta di registrare alcune delle chiamate ai mock e a campione verificare che il sistema terze parti funzioni, in uno step separato non facente parte della ci cd.
Simpatico questo sistema di health check terze parti, immagino sia la conseguenza di mille compromessi e necessità di tenere su servizi e dare una buona comunicazione quando qualcosa non va…
Comunque dagli un’altra chances al mock e2e, niente ti vieta di registrare alcune delle chiamate ai mock e a campione verificare che il sistema terze parti funzioni, in uno step separato non facente parte della ci cd.
Simpatico questo sistema di health check terze parti, immagino sia la conseguenza di mille compromessi e necessità di tenere su servizi e dare una buona comunicazione quando qualcosa non va…