Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.

Lo so, lo so, è passato un po' di tempo dall'episodio del FOSDEM, in realtà l'avete sentito qualcosa tipo due settimane fa, però da questo momento effettivo sono solo passati alcuni giorni e io mi sto ancora riprendendo, devo dire che è stato un po' faticoso, 1600-1700 km in totale tra andata e ritorno in macchina, poi due giorni di conferenza a bella attesa, quindi insomma adesso andiamo slow, ma Geekbar non si ferma, infatti oggi registriamo un nuovo episodio.

Di cosa andiamo a parlare oggi? Oggi per un attimo ho avuto un flashback, no? E sono tornato indietro una decina d'anni fa, così a spanne più o meno, sì una decina d'anni fa, quando ancora lavoravo in PHP, c'era Symfony, c'era Behat, c'era il Gherkin e c'era Selenium.

Io lo ricordo bene quel momento, da allora ad oggi nel mio percorso professionale tante cose sono cambiate, così come buona parte dell'ecosistema è cambiata, però l'esigenza di fare dei test end to end rimane e forse è sempre più forte di ieri.

Ma la puntata di oggi non è un mio monologo sul test end to end, per quello trovate uno o due episodi dove sproloquio per qualche buona mezz'oretta sul testing, ma abbiamo un super ospite, un ospite che vi presento subito dopo avervi ricordato rapidamente i nostri contatti.

Info www.github.it e brainrepo sono su Twitter, sono i modi canonici per contattarci.

Esiste però il gruppo Telegram che ormai buona parte di voi conoscono, ma non tutti, per cui se ci state ascoltando e non vi siete ancora iscritti al gruppo Telegram, sappiate che è là che succedono le cose, è là che trovate tutti gli stimoli e le robe fighe e incontrate la nostra community di più di 1200 membri.

Detto questo io direi che vi ricordo rapidamente due cosine.

A.

Github ha completamente eliminato le pubblicità, è stata una scelta non troppo sofferta ma abbastanza determinata, quindi da queste puntate in poi non sentirete almeno per ora nessun tipo di pubblicità.

Questo ci è utile per le transcription in modo da avere dei punti fermi su cui appunto tarare e marcare ogni parola, visto che le pubblicità di Spreaker erano la roba meno reliable del mondo, cioè facevano shiftare la lunghezza dell'episodio a fisarmonica in modo non predicibile.

Quindi se ci volete supportare avete un modo per farlo, andate su iTunes, lasciateci un commento, una stellina o una stellina su Spotify oppure supportateci con una donazione.

Non perdo troppo tempo per questo e andiamo subito al solo.

Benvenuti su Github, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Eccoci qua, eccoci qua, l'ospite di oggi è Giovanni Rago, Head of Customer Solutions per Checkly, è un ambassador, uno dei pochi ambassador di Playwright, è anche host del canale YouTube Automate Together.

Ciao Giovanni! Ciao, che piacere di essere qui! Il piacere è tutto nostro, finalmente riusciamo a registrarla questa puntata, devo dire che con Giovanni abbiamo pianificato questa registrazione da un po' di tempo no? Si è vero, è vero, qualche settimana, ma per me sono volati a dire il vero, periodo intenso.

Anche per me, devo dire.

Levami una curiosità, Head of Customer Solutions, che è? Eh lo so, è difficile trovare il nome giusto per questo genere di posizioni, è un po' ibride che trovi spesso nelle start up anche no? In generale, allora se lo devo spiegare, che cosa fa Customer Solutions e Checkly? È un team piccolino, siamo io e altri due ragazzi, è un po' una fusione fra il Solutions Engineering, che già come nome so per tanti che non l'hanno mai sperimentato, sembra la cosa più generica del mondo, Solutions Engineering, anche conosciuto come Sales Engineering, con altri 30 nomi, e Customer Success Management, quindi al di là dei paroloni, che cosa si fa? Si lavora coi clienti e coi futuri clienti, lato tecnico.

Quindi io ho una formazione da informatico, però non lo so, all'inizio della mia carriera devo aver fatto un passo falso, sono finito più lato sales diciamo, e no, adesso scherzi a parte, mi piace sempre molto lavorare con i clienti, vedere i business di diverso tipo, come si interfacciano con le tecnologie, come ad esempio insomma quella che offre Checkly.

Quindi io in sostanza faccio un ruolo in questo momento che è ibrido, siamo appunto un team piccolino, quindi non faccio management tutto il tempo, e sono diciamo part-time manager se vuoi, e sono anche sempre molto front line su Solutions Engineering, e in generale provo diciamo a stare a fianco dei nostri clienti e ad aiutarli ad ottenere il massimo nel campo specificatamente in questo caso del Synthetic Monitoring.

Ecco, ci racconti rapidamente, perché è una cosa che mi ha incuriosito da subito, cosa ha fatto in Checkly e cos'è il Synthetic Monitoring? Sì, allora, il Synthetic Monitoring è una, possiamo dire, una branca del monitoring, che ovviamente può voler dire tante cose, nello specifico il Synthetic Monitoring è quella parte di monitoring che crea traffico sintetico per andare a verificare lo status di un sistema, un sistema che può essere un API, può essere una web app, no? Noi quindi che cosa andiamo a fare? L'esempio più noioso del mondo.

Se il cliente, il nostro cliente magari, che ne so, gestisce un web shop di un qualche tipo, no? Il cliente va ad identificare quelli che sono i, diciamo, quelli che chiamiamo Key User Flows, quindi i percorsi utente più importanti, che appunto nel caso di uno web shop saranno, l'esempio classico è arrivi sulla pagina, inserisci un item nel carrello, poi fai la procedura di checkout, no? L'idea è che ovviamente, immagino tutte le persone che ascoltano questo podcast capiscono benissimo che dietro le quinte di una cosa che può sembrare così semplice possono, come dire, ci sono un miliardo di cose che possono andare storte e quindi noi andando a creare, noi siamo un servizio SaaS, no? Andiamo a creare un browser headless in cloud che appunto avendo sotto il cofano Playwright va a ripercorrere questi step, a navigare sulla pagina, arrivare al checkout dopo aver inserito l'item nel carrello e verificare che questo flow funziona.

Lo facciamo di continuo, no? L'idea appunto è quando qualcosa smette di funzionare, che sia a livello infrastrutturale, che sia un bug che va in produzione, noi come dire, diamo questo feedback al nostro cliente in tempo reale tramite alerting, tramite pager duty, tramite SMS, messaggi su Slack, qualsiasi cosa, tutto automatizzato e diamo le informazioni che servono a, insomma, a un malcapitato che deve rispondere all'incidente per risolverlo il prima possibile.

Insomma, questa è un po' l'idea del synthetic monitoring.

Dall'altro lato magari c'è il real user monitoring che è più, come si dice, è complementare che invece va a guardare, come dire, quello che fanno gli utenti reali, in qualche modo, non incontrano errori, incontrano problemi, noi invece quegli utenti li creiamo appunto in maniera sintetica.

Io vengo da un ambiente, un mondo dove questo tipo di testing viene fatto in house, no? Quindi quando sviluppi una soluzione fai questo tipo di copertura.

E quello che mi chiedo è, ad oggi dal tuo punto di vista, sono molte le società e le aziende che invece non lo sviluppano in house, questo tipo di azione, di strumento? Intendi proprio il sistema di monitoring o la parte proprio di scripting invece dei test, diciamo? Sì, la parte di scripting, perché la vostra parte è scriptabile, no? È l'utente che praticamente va a costruire i suoi test.

Esatto, esatto.

Ok.

Sì, io ho visto entrambe le cose, devo dire, in passato, guarda ti do giusto un po' di background, così capisci quello che ho visto prima, insomma.

Io adesso sono a CECLI da tre anni, praticamente da quando esiste, all'inizio eravamo 4-5.

Prima però ho lavorato per, insomma, la mia carriera, quando mi sono trasferito in Germania, ho iniziato con una piccola startup, TestObject, facevamo anche lì una soluzione in cloud, ma per il testing, non monitoring, ma proprio testing su dispositivi reali, esperienza molto interessante, che poi è stata comprata da Sauce Labs, che fino a quando me ne sono andato, è stato uno dei leader di quel settore, è stata dietro a Selenium, tantissimo, insomma, un pezzo grosso del settore, e devo dire, interfacciandomi allora, adesso a CECLI siamo ancora piccolini, ma interfacciandomi con le grandi aziende ai tempi di Sauce Labs, ho visto tante cose, ho visto aziende in cui si faceva tutto in house, ho visto dell'outsourcing anche bestiale in certi casi, in cui, insomma, poi mi vengono in mente un paio di, come dire, di storie dell'orrore, ma...

Sì, il tipo, il team di Mechanical Turk, o simil Mechanical Turk dall'altra parte del mondo, che cercano di fare copertura di testing, cose di questo tipo, immagino, no? Sì, guarda, te ne racconto una, perché è troppo spassosa, non riesco a trattenerla.

Per questa, insomma, capita ovviamente che quando ti intendi di test automation, magari c'è qualcuno all'alto sales proprio, che si sta interfacciando con un cliente, o un potenziale cliente, insomma, e si è in questa situazione in cui, come dire, il cliente o il tuo contatto principale non è quello che è stato dietro l'automazione, ma ne è responsabile, appunto l'automazione viene fatta magari offshore, no? E mi viene in mente appunto questa chiamata in cui io maldestramente stavo provando a indicare appunto a un programmatore dall'altro lato che si occupava dell'automazione un determinato errore che avevo visto, eravamo in screen share, no? Un determinato errore che avevo intravisto nel codice, e non so perché non mi è venuto in mente di dirgli, insomma, non stavo riuscendo a dare indicazioni precise sul punto esatto del codice, no? E quello che è successo è che il mio collega che era in chiamata con me dice sì, sì, sta dicendo lì di fianco a questo numero qua 27165, che ne so, no? E io era anche mattina presto, mi sa, quindi andavo ancora preso il caffè evidentemente, dico che si sta dicendo 27165, qui stiamo guardando degli script di Selenium, e poi guardo, capito? E il fatto è che 27165, quella era la riga, era il numero di riga di codice, quindi noi stavamo...

Ah, aiuto! Noi, eh lo so, fa male, noi stavamo guardando ed eravamo a un terzo, cioè il framework di automazione che era stato costruito appunto in outsourcing, eravamo a un terzo di questo enorme file Java che conteneva tutto, puoi immaginarti le variabili globali, i casini e tutto, e il file sarà stato 60-70 mila righe, qualcosa del genere, quindi ecco, se volevano una war story insomma, ho visto anche...

Ma questo è peggio! No, in realtà questo mi porta a farti una domanda, è una riflessione che ho fatto qualche settimana fa nell'episodio natalizio, no? Tu hai a che fare prevalentemente con...

anzi, potresti avere a che fare con due figure diverse, potresti avere a che fare con i software engineer oppure con i test engineer, no? Che hanno due forme mentis leggermente diverse, che differenza trovi tra queste due figure? Nella tua esperienza sai, confrontandoti col cliente, anche col reparto tecnico poi del cliente, essendo comunque un solution...

mi viene da dire un solution architect, però più o meno il ruolo è quello se ho capito bene.

Sì, sì, cioè c'è molto overlap almeno.

È un'ottima domanda, e come dire, se ne potrebbe parlare davvero a lungo.

Diciamo in passato mi sono interfacciato di più con proprio QA puri, quindi tester tester, diciamo, test automation engineer, fino a less debt in sostanza, e anche diversi sviluppatori puri.

Queste erano un po' le figure.

Oggigiorno continuo a interfacciarmi sempre un po' con QA automation engineer, eccetera, però mi interfaccio decisamente di più con sviluppatori, SRE, DevOps engineer, questo tipo di figure qui.

La differenza grande...

da dove cominciare? Allora innanzitutto, guarda, partiamo da qui.

Nella mia esperienza, e adesso qui per dire qualcosa un po' dobbiamo generalizzare, quindi non me ne vorranno gli ascoltatori quando magari non si riconoscono in quello che dico, però almeno in passato, diciamo, è una cosa che si nota ancora, nel campo del testing puro, come dire, c'è stata una fetta della popolazione che ha, secondo me, seguito un po' e ha capito fin dall'inizio magari, o più avanti, il senso della test automation e che cosa appunto la test automation fa e dove in un contesto di sviluppo agile si inserisce.

C'è anche una frangia, come dire, magari che ha un po' più uno skillset da puro testing manuale, che spesso, come dire, non si trova, diciamo, in un contesto di alta automazione.

E poi c'è anche una frangia oltransista che dice proprio test automation è un, come si dice, è uno simero, non si può automatizzare il testing, eccetera, eccetera.

E quindi da quel lato lì si trovano anche più, mi manca la parola adesso, però, più scontri ideologici quasi, nel senso, gente che investe molto sull'automazione sì, automazione no.

Io ho notato invece, lavorando più con sviluppatori, SRI, eccetera, c'è un approccio semplicemente pragmatico, nel senso, oggigiorno l'automazione e il lato testing ti serve e non ti fai neanche troppe domande.

È ovvio che c'è una grossa, come dire, non è un discorso semplice avere una strategia di testing, come fare l'automazione, eccetera, eccetera, possiamo parlarne molto a lungo.

Però, sì, con gli sviluppatori diciamo, di solito, non c'è quel, sì, c'è un filo o meno di ideologia, nel senso.

La cosa che, ti faccio un esempio pratico.

Questa è una cosa che ho notato e noto di continuo, anche perché adesso, come dire, in passato ho utilizzato molto Selenium, poi è stato fuori Cypress, poi oggigiorno mi occupo principalmente di Playwright, che è il framework in cui credo di più, come possibilità future, eccetera.

Però ogni volta che uno esprime in un qualche forum pubblico, si esprime a favore o contro, in un qualche modo, insomma, di un tool di automazione, c'è sempre una, come si dice, una risposta molto, molto infiammata, diciamo, molto vigorosa.

Cioè la gente che ha investito molto su Selenium, che ne so, ad esempio, magari invece di aver provato un po' tutti i tool, capito, di saltare dall'uno all'altro a seconda del progetto, del contesto in cui si trova, del target di automazione, eccetera, si trova magari gente che, che ne so, è talmente investita su Selenium che non ti può accettare che, che ne so, magari Cypress effettivamente è un'esperienza, una developer experience molto accattivante, quindi la gente che lo usa, a sé, c'è una ragione se lo usa.

O, che ne so, magari anche gente che invece è molto, molto intrippata con Cypress, magari non, quando gli porti un argomento magari a sfavore, come dire, un po' se la prende.

Non ci è notato molto questa cosa, che secondo me, come dire, da informatico mi sembra un po' strana, no? Però, d'altra parte, insomma, ci sono le flame wars, si trovano sempre, no? Ci si vogliavo.

Sì, ma infatti sta nell'ordine delle cose.

La lotta continua e noi lo diciamo sempre, che qua a Gitbar, che crediamo che una parte di queste flame wars sia, venga dalla gestione del caricocognitivo, nel senso io mi sono studiato Selenium, me lo difendo fino alla morte perché non ho un cazzo di voglia di studiare Cypress o Playwright, perché è un effort, diciamoci la verità.

Comprensibile, è anche vero, è vero, è vero.

E secondo me, e ne sono fortemente convinto, questa cosa è il driver principale.

Abbiamo parlato di sviluppatori, abbiamo parlato di testing, io, vabbè, sono un po' opinionato perché per me l'end-to-end testing fa parte della fase di scrittura del codice.

Quindi gli script d'automazione fanno parte della fase di scrittura del codice come il rompitorio umano, così lo chiamo io, quindi il QA che va a testare l'app fa parte, dal mio punto di vista, del prodotto design.

Sono due ruoli completamente diversi, no? Per me il rompitorio umano, quindi quella persona che scassa l'applicazione inventandosi degli user flow impossibili, ci deve sempre essere perché è il generatore di entropia fondamentalmente all'interno del processo.

Cosa che magari in uno script d'automazione, sì, vabbè, si può generare l'entropia ma non quanto una persona che sa veramente rompere l'applicazione.

Ne conosco un paio, vi giuro, sono state in grado di rompere le cose più robuste del mondo.

Però, ritornando alla parte dello sviluppatore, esiste una linea sottile che separa i diversi tipi di test, no? Test unitario, test d'integrazione e test end-to-end.

Specialmente tra la linea dei test d'integrazione, dei test end-to-end, talvolta questo confine è un po' sfuocato, no? Dal tuo punto di vista, come possiamo capire se il test che stiamo facendo o la feature che vogliamo testare o l'elemento dal quale vogliamo proteggerci deve stare su un test end-to-end o su un test d'integrazione? Questa è un'ottima domanda.

È anche un po' stronza, abbi pazienza.

No, no, mi piacciono le domande stronze.

Io ti direi, guarda, qui siamo secondo me nel senso...

Sì, siamo un po' nel dominio delle opinioni, esatto.

Io ti potrei dire, guarda, se vogliamo farla semplice, quando guardiamo proprio all'end-to-end, se lo intendiamo nella, come dire, nell'accezione classica, io lo vedo come davvero far partire dall'inizio, o meglio, far partire il test o lo script o il case, insomma, come vuoi, dall'inizio dell'interazione utente alla sua fine, no? Che anche lì, ovviamente, stiamo concettualizzando.

Però io direi a quel punto tutto quello lo possiamo confortevolmente chiamare end-to-end testing.

Poi il resto, insomma, quello è già un bel chunk, una bella fetta che tagliamo via.

Poi non so che cosa aggiungerei.

Dipende anche da che cosa vogliamo fare, di preciso.

No, sono pienamente d'accordo con te su questa cosa, anche perché quando si parla, anche questa è un'opinione mia, di test end-to-end, secondo me si deve ragionare con lo use case in testa e con l'utente.

Sono dei test user-centrici, ok? Invece i test d'integrazione hanno come focus principale, hanno come spotlight direttamente una luce che punta sulla feature, sulla parte architetturale, sull'integrazione di diversi moduli, sull'integrazione con la platform.

Quindi cambia l'approccio.

Se io sto testando da ingegnere, probabilmente non farò un test end-to-end ben fatto, a meno che il product designer viene da me e mi dice guarda che gli user flow sono questi, rompimi lì.

E qua abbiamo, si apre un altro problema, un altro mio dilemma, alla quale secondo me non esiste risposta, però io provo a farti questa domanda.

Io non sono riuscito a dare la risposta, quindi sentiti libero di dirmi che domanda del cazzo.

No, la domanda che mi pongo è, anche perché ne parlavo con un collega proprio stamattina.

Secondo te, il mocare i servizi esterni ha senso nei test end-to-end? Ed è un rischio nei test end-to-end? Si collega un po' alla domanda di prima, no? Test integrazione o test end-to-end? Sì, ottima domanda anche questa.

Guarda, secondo me, nel senso, io sarei molto, quando parliamo proprio di test end-to-end, come li abbiamo definiti prima, io sarei molto, ovviamente sono sicuro che ci saranno i casi specifici in cui questo non vale, però io sarei, farei attenzione insomma al mocare i servizi esterni.

Nel senso adesso io ti parlo, magari adesso ho il bias appunto del synthetic monitoring in cui tu vuoi effettivamente andare, come dire, sei in production, no? Quindi, te ne so, se le cose si rompono a causa di una di un API ter party, che ne so, comunque lato utente le cose non funzionano, no? E quindi io ho talmente, come dire, ho quello in testa adesso.

Immagino che ci possano essere dei casi in cui comunque si vuole fare, però io personalmente lo vedo più preponderante lato integration test proprio che non full end-to-end, diciamo.

Sì, sono d'accordo con te.

Allora, anche qua ti dico quella che era la mia posizione con la collega.

C'è da fare una distinzione sui test end-to-end.

Se sono dei test, io li chiamo da pipeline, o dei test on-prod, quindi degli smoke test, sono quei test, per chi non lo sapesse, che semplicemente ti devono dire in qualche modo, qua c'è il rischio di bruciato, qualcosa sta andando a fuoco perché questo user journey è interrotto da qualche parte, quindi potrebbe esserci un problema più grande.

Perché, faccio un esempio proprio, l'esempio della serva, non più lontano di ieri, noi avevamo un test end-to-end che faceva, c'era un drop down stupidissimo, un autocomplete col drop down stupidissimo che faceva delle API a Google places per fare l'autocomplete dell'address.

Peccato che zio Google, in modo del tutto intelligente, ha dei rate particolari, dallo stesso IP, e spesso si incazza se tu fai troppe chiamate in un certo lasso di tempo.

Fondamentalmente noi avevamo una serie di test suite di un po' di test che andavano a toccare, a insistere su quella feature, e quindi andavano a fare queste chiamate e Google iniziava a rispondere errore rendendo i test, dei test flaky.

E questo è tipo il terrore più grande di chi fa dei test end-to-end, tipo di te, la cosa, il dolore che capita spesso ed è sempre predictable.

Allora di là che fai? Mocchi.

La mocchi però se in pipeline è poco male.

Secondo me ecco il mocking nei test end-to-end, non in ambienti di produzione, ancora ancora ci sta, ok? Anche se in realtà ti sta nascondendo dei potenziali rischi, dei potenziali non funzionamenti, perché l'end-to-end deve toccare ogni margine del tuo sistema.

Però degli smoke test on-prod, a quel punto non ha senso farli per niente.

Sono completamente d'accordo, nel senso a quel punto rischi davvero di, come dire, accecarti volontariamente in qualche modo, perché invece quel feedback lo vorresti avere.

Sì, no, sono d'accordo su questo.

Abbiamo parlato tantissimo di testing, ma allora andiamo ai giocattoli, no? Playwright, arriva Playwright e in modo anche abbastanza, devo dire a livello di marketing, abbastanza prepotente.

Cioè si è fatto spazio nel panorama delle soluzioni per il testing in modo così forte.

Perché, cosa pensi abbia portato a Playwright la capacità appunto di aprire un varco così grande? Allora io innanzitutto penso che una cosa importante sia anche nella storia di Playwright in un qualche modo.

Adesso è passato un po' di tempo, ma spero di essere, di riportare i fatti in maniera accurata.

Però in sostanza prima di Playwright c'era Puppeteer, no? C'era Puppeteer, appunto, testing library volendo, no? Sì e non solo, per esempio, diciamolo agli ascoltatori sanno che le copertine del podcast sotto il cofano hanno Puppeteer che fa il rendering di un'applicazione in Cina React.

Esatto, quindi c'era Puppeteer per quello, per scraping, insomma per tanti tanti utilizzi.

E Puppeteer già di suo, insomma, era un tool interessante, no? Io lo vedevo col cannocchiare dal campo di Selenium volendo e in sostanza, come dire, Puppeteer si è sviluppato fino a un certo punto sotto, insomma, sotto lo standard di Google comunque.

Dopodiché il team, penso nella sua interezza, in sostanza è stato poi assunto a Microsoft, no? Per costruire Playwright.

E secondo me questa è una chance, io direi, quasi più unica che rara, nel senso hai modo di, come dire, di costruire un tool, di fare tutti gli errori, no? Come dire, arrivi qualche anno dopo che dici, ah, se, capito, se l'architettura l'avessimo pensata in maniera leggermente diversa, se l'avessimo posizionato in maniera un po' diversa anche lì e tutto e poi hai effettivamente la chance con la stessa gente, nel senso con le persone che conosci e tutto, con le dinamiche già un po' create, di andare a rimediare a tutti, magari tutte le cose che avresti voluto cambiare, avresti voluto fare diversamente.

Quindi Playwright è uscito, è uscito fortissimo, insomma, già dalla fabbrica.

La versione è ben riuscita del piano di Ryan Dahl con Dino.

Sì, esatto, esatto.

Io, fra l'altro, nel senso è chiaro comunque che Microsoft ci ha messo anche un certo peso dietro a Playwright, perché comunque anche solo guardando la velocità con cui si è sviluppato, no, nel senso, tutte le feature, comunque, release a cadenza mensile con nuove feature ogni volta, roba grossa, e comunque anche un po' di marketing ben pensato, diciamo, un'immagine, come dire, curata da tool di testing per sviluppatori, bello accattivante in un qualche modo, documentazione ottima, nel senso...

Beh, il know-how che ha fatto Microsoft con GitHub, con Visual Studio Code, con tutti gli altri, insomma, ci sta, è classico.

E c'è anche il sordo, secondo me, come si suol dire, che fa la differenza.

Domanda, quanto rimane di Puppeteer dentro Playwright? Perché il team, hai detto che parte e lo stesso devono aver strappato i contratti di non competizione di un tempo, non so se te li ricordi, no? Dove facevano gli accordi, io non assumo i tuoi, tu non assumi i miei, una roba del genere.

No, però, quanto rimane di Puppeteer dentro Playwright oggi? Oddio, sotto il cofano è stata, da quello che mi ricordo io, è stata riscritta tantissima roba, proprio.

Quello che rimane, lo vedi un po' magari nella forma delle API, no? Però anche lì, come dire, tutto il meccanismo, diciamo, è proprio l'impostazione completamente diversa, no? Cioè Playwright nasce cross browser, no? Mentre Puppeteer lo era per finta, diciamo.

E Playwright ha questo sistema di auto-weighting, no? Built-in, con gli actionability check, che è, come dire, su cui hanno chiaramente investito molto.

Perché ovviamente non può funzionare in tutti i casi, non...

Quella è una cosa pressoché impossibile.

Però funziona davvero bene, c'è da dire.

Secondo me sono quelli che l'hanno azzeccato meglio di tutti, probabilmente, fino a questo punto.

Quindi non rimane tantissimo, però probabilmente rimangono le lezioni, in un qualche modo.

Quella era la cosa fondamentale.

L'altro grande che Playwright è riuscito in qualche modo a mettere in difficoltà è Cypress, no? Togli Selenium, che comunque aveva il suo mondo e già, insomma, qualche schiaffo l'ha sentito da Cypress, no? Però Cypress era molto verticale nel mondo front-end, nel mondo JavaScript.

Playwright, da quello che ho visto, non sono un esperto, corregimi se sbaglio, si pone in modo un pochino più orizzontale, no? Per esempio è aperto a più linguaggi, se ricordo bene.

Sì, guarda, allora, è anche interessante, secondo me, la storia di Playwright, che secondo me molti utenti nuovi non sanno.

Ma, come dire, Playwright non è nato nella forma attuale, diciamo.

Cioè all'inizio Playwright, 2020, in gennaio 2020, penso la prima release, era sostanzialmente una libreria, cioè era molto più simile a Puppeteer, in un qualche modo.

Cioè era proprio un tool, se vogliamo dirla tutta, principalmente per sviluppatori web, per developer proprio.

Nonostante, come dire, si dicesse già testing framework, in un qualche modo.

Era ottimo per tutti gli scenari citati prima, cioè scraping, testing, synthetic monitoring, eccetera.

Quello che ha fatto per appunto piazzarsi in maniera più orizzontale, mentre prima era molto verticale anche lui, è stato appunto la trasformazione in quello che si chiama, ok, oggi lo si chiama anche semplicemente Playwright, ma fino a poco fa almeno si chiamava Playwright Test, no? Adesso Playwright sotto il sombrello ha due grossi componenti, se vogliamo semplificare.

La Playwright Library, che era il vecchio Playwright, tutto il core, diciamo, tutte le API, tutta la parte interna, diciamo.

E poi c'è la parte test, che è il test runner, diciamo, e tutti i vari tool di debugging, test generation, il recorder in sostanza.

E l'aggiunta comunque di tutto questo runner, diciamo, che prende molto da Jest, no? Ricorda molto, insomma, per tanti aspetti e tutti questi altri tool, appunto, che ho menzionato prima, il trace viewer anche, tutte queste cose rendono, in qualche modo, lo rendono molto più accessibile e con l'aggiunta di queste feature, secondo me ha chiuso o sta chiudendo, insomma, molti magari dei gap che aveva specialmente con Cypress, ad esempio.

Direttamente di Developer Experience, penso al debugging principalmente, no? Test generation, eccetera.

Quindi c'è stata una grossa trasformazione lì.

Se dovessimo paragonarlo a Cypress, secondo te quali sono i plus di Playwright? Quali sono, diciamo, quegli elementi che ci farebbero dire, ok, uso Playwright e non uso Cypress? Io qualcuno ce l'ho in mente, ma mi piacerebbe sentirli da te.

Sì, allora, innanzitutto, voglio dire che i tool che abbiamo menzionato fino ad adesso sono tutti ottimi tool.

Nel senso, Cypress ha, secondo me, una Developer Experience fantastica, ad esempio.

Cioè, mi ricordo, capito, anche quando ero molto investito appunto nel mondo Selenium, utilizzavo Appium, insomma, ero abbastanza in ambiente WebDriver, provare anche le prime versioni di Cypress, ero lì, cavolo, insomma.

Ci aveva una UI figa, per chi veniva da Selenium diceva questa UI è spettacolare.

Insomma, più che fare un raffronto, magari, fra tutti, ti dico, anni fa feci, scrissi un articolo, penso che sia ancora una delle pagine più visitate del nostro blog di Cekri, fra l'altro, in cui andavo a paragonare, facevo un benchmark abbastanza crudo volendo, però comunque volevo, come dire, avevo delle domande su cui volevo un paio di risposte.

Questa domanda viene proprio da quell'articolo.

Sì, avevo in sostanza fatto appunto un benchmark fra, adesso non mi ricordo quali avevamo incluso, comunque mi sa che c'erano Puppeteer, Selenium tramite WebDriver I.O., se ricordo bene, Cypress, eccetera.

E ovviamente non ti dico la controversia, cioè tutti me ne hanno volute, insomma, mi hanno redarguito da tutti i lati proprio su quello che secondo loro non andava bene, ma non c'era altro modo di farlo, in sostanza.

Però sì, insomma, quello poi informò anche quel benchmark alla nostra decisione di focalizzarci su Playwright.

Devo dire, è sempre difficile fare raffronti fra i framework in questo modo, specialmente perché non sono tool che usi così come sono, vanno configurati in un certo modo, possono essere utilizzati in diversi modi per diversi scenari, insomma, è complicato fare un raffronto importante.

La cosa che ti posso dire, in qualche modo posso rigirare la domanda, è dirti il perché secondo me Playwright è così interessante versus...

Sì, io non volevo ragionare in termini di performance, volevo invece parlare in termini di feature.

Sì, sì, proprio quello, anzi, guarda, ti dicevo, mettendo assieme tutto, la cosa che fa risaltare, che mette in risalto Playwright rispetto agli altri tool, è che è un po' forte da tutti i punti di vista, no? Nel senso, la developer experience di Playwright, specialmente dopo questi ultimi sviluppi, secondo me è praticamente best in class.

La performance come tempo di esecuzione degli script è un tool estremamente veloce.

La stabilità, per me, venendo dal synthetic monitoring, in cui, come dire, false failure, c'è un test che fallisce quando non dovrebbe, quando non c'è un problema col sistema under test, insomma, col sistema che stai monitorando, quello vuol dire che magari qualcuno viene svegliato da pager duty alle 2 del mattino, quindi non, come dire, lì devi davvero guardare con una certa serietà.

La flessibilità, comunque, che ti permette, no? Cioè il numero di, come dire, la profondità e l'agilità con cui puoi utilizzare i browser, no? Anche se non fosse, come dire, il numero uno in nessuno di questi campi, e lì ne potremmo parlare, il discorso è che è forte in tutti.

Ed è questo, secondo me, che lo rende così appetibile un po', sia lato sviluppatore, sempre di più, anche lato test automation, QA, QA engineer.

Sì, c'è da dire che, per esempio, io ti porto...

Sai, in azienda abbiamo fatto dei POC, abbiamo fatto un po' di discovery, perché buona parte dei test end-to-end li abbiamo fatti sempre con Cypress, no? Da quando esiste.

E quindi, almeno per quanto mi riguarda, io ho sempre usato, subito dopo Selenium, ho utilizzato Cypress e così sono andato.

Un paio di cose che mi hanno catturato l'attenzione sono state, in primis, il supporto di più linguaggi.

Anche se il web, fondamentalmente scritto in JavaScript, aver la possibilità di scrivere le test suite in più linguaggi, questo è un grosso vantaggio, perché ci possono essere altri scenari che noi stiamo trascurando.

Raga, stiamo facendo girare Python nei browser, qualcosa vorrà dire, nel senso, qualcosa sta cambiando da quel punto di vista.

Lo vedremo poi più avanti, però già col concetto di WebAssembly tu stai portando degli skill differenti nel mondo del web, skill che potrebbero essere opinionati o spinte a utilizzare il loro linguaggio piuttosto che il JavaScript, no? Certo.

Lo, molto semplicemente, facendo due passi indietro, io ricordo me che utilizzavo o Gherkin o PHP per pilotare Selenium con MincMonk, non mi ricordo come si chiamasse quella libreria.

Insomma, quindi quello è un plus.

Un'altra cosa che ho notato è che ho invidiato...

Supporto multitab o...

No, il parallel testing.

Il parallel, ok.

Perché Cypress è fatto in modo diverso, ha proprio una filosofia differente, no? Esatto, e quella è una cosa che ho invidiato di brutto.

Un'altra cosa che ho invidiato di brutto, non so come si chiami il nome specifico, però è la parte di await.

Sì.

Cioè, la scrittura dell'esperienza utente nell'utilizzo di questa funzionalità fa sì che...

Cioè, questa funzionalità fa sì che l'esperienza utente nella scrittura del test sia molto più fluida al posto di fare dei giri come quelli che facevamo con Cypress talvolta.

Auto-wait, altra cosa.

Io penso di aver pianto non più tardi di qualche ora fa mettendo Interceptor, facendo l'attesa sull'Interceptor.

Cioè, raga, volevo spararmi i piedi.

Quello è un...

come dire, il topic del waiting, dell'aspettare che qualcosa succeda in maniera...

Adesso mi vengono solo parole in inglese, devi perdonarmi, ormai sono le 10, quindi l'italiano sta svanendo.

Quindi fare waiting, no? Dovere avere un modo, come dire, facile da gestire che poi non vada a creare invece appunto dei falsi positivi è un argomento inesauribile.

Cioè, ogni volta che facciamo, ogni volta che mi trovo a parlare con persone che scrivono script in questo o in quel framework è quasi sempre la cosa che mi viene chiesta di più e non importa quante conferenze vai, quanti workshop fai, eccetera, trovi sempre tantissime persone che usano i sleep in sostanza, no? Cioè, che mettono, ok, qui aspettiamo 10 secondi, capito? E speriamo che poi la cosa che deveva succedere sia successa.

Esatto, io porto la mia esperienza con Cypress.

Metti un interceptor, aspetti, ascolti, metti il wait sull'interceptor, ok, sono sei righe di roba, cinque righe di roba.

Che, insomma, anche ricordarti la sintassi, quindi fai un salto nella documentazione per vedere che non stai facendo cappellate, perché...

Anche per la leggibilità, fra l'altro, no? Esatto, anche, anche, esatto.

E poi cosa fai? Metti l'only sulla parte di test, te la runni in visuale, speri che funzioni, insomma, raga, è tempo, quindi molti di noi cosa fanno? Sbagliando a palla.

Mettono un bel wait, 500 millisecondi, e quello in un modo o nell'altro, insomma, funziona, ti porte a casa il test.

Peccato che cambia il contesto, gira in CI, e quel test fallisce, diventa un flicky test.

A volte fallisce, a volte succede, le bestemmie, rerunare la CI, e me ne falliscono 7, 10, 15, questa cosa poi diventa esponenziale, fuori controllo, ti incazzia, prendi e cancelli la...

se ne è la possibilità, prendi e cancelli la test suite end-to-end e dici, vaffanculo, me le prova a mano.

Io queste scene le ho viste.

Ah, scherzi, ma poi il discorso è...

mi ricordo questi tempi di Selenium per me, ma appunto tempi di testing, lavorare, interfacciarmi con grandi aziende, alcuni comunque avevano delle suite di test appunto che giravano su commit magari, che giravano sul deploy, capito? Magari dovevano far girare una test suite immensa, tantissime volte al giorno, e comunque se tu inizi ad aggiungere 10 secondi qua, 10 secondi là, sbagli la parallelizzazione, eccetera, a un certo punto devi...

diventa davvero come all'epoca quando potevi andarti a prendere il caffè, perché tanto non...

capito? Sei lì che aspetti che finisca tutto prima di poter andare.

Giovanni, nel progetto dove sono, 25 minuti ogni PR.

Di cui 18 minuti, 19 minuti stanno su Cypress.

Adesso ci sono tanti wait 500 e wait 1000 da rimuovere e piano piano insomma si stanno rimuovendo, però in realtà sono un indicatore, perché comunque tu devi mettere il wait e nel mio caso devi anche mettere la regola per far star zitto l'Inter, perché io da furbo quando ho fatto il setup del progetto ho detto ok, facciamo una cosa, mettiamo una bella regoletta dell'Inter in modo da creare attrito verso questa soluzione, però nonostante la regoletta dell'Inter, quella rimane ancora la soluzione più rapida per lo sviluppatore e questa cosa fa sì, cioè questa cosa evidenzia il fatto che il problema sia un mero problema di Dev Experience.

L'auto wait in qualche modo nasconde, elimina quest'attrito dal mio punto di vista, rende tutto più smooth, tutto più fluido ed evita questo tipo di loop e soprattutto fa sì appunto che non si crei questo modo, che non si generi la causa di questa perdita di tempo.

Facciamo un passo per un attimo sul parallelo invece.

Quella sai perché secondo me è una roba molto figa? Perché una cosa che mi è capitata da poco in un progetto dove stavo dando consulenza è stata quella di avere dei test che erano in qualche modo dipendenti l'uno dall'altro.

Ok, adesso noi siamo tutti bravi, tutti facciamo i test isolati ma non è vero no? Perché capita, perché siamo esseri umani e perché talvolta la merda la scriviamo a palate.

Io sono il primo che lo fa.

Runnare i test in parallelo può essere un modo per spottare questo tipo di problematica? Sì, sicuramente.

Io qui tendo ad essere un po' nazi, rischierzo, esatto, però un po' estremista nel senso che poi ho lavorato in campo testing per aziende che come dire puntavano molto sul fatto che si sfruttasse la capacità di parallelizzazione di quelle che erano magari grid in cloud in sostanza.

Quindi questo era sempre un grosso topic ma in realtà al di là di quelli che potevano essere gli interessi aziendali ha proprio senso stare attenti a queste cose qui.

Il discorso è sempre, per ricollegarmi un attimo a quello che dicevi prima sulla flakiness, ogni volta che c'è un false positive, un test fallisce quando non c'è una vera ragione del sistema che sta venendo testato affinché questo debba fallire.

Non è solo che come dire come si dice da dove vengo io da Bologna ti scende la catena ma c'è proprio il problema che piano piano è quella goccia che si dà alla nota.

Il problema è che più succede più, e questo è un problema molto sottovalutato secondo me, più il developer o chi per lui inizia a perdere un po' la fiducia in questo sistema di automazione che è stato scritto.

Si guarda ho controllato per la ventesima volta ho mille cose da fare sono a ritardo sulla deadline mi è arrivata la notifica qui che questo test ha fallito per l'ennesima volta.

Sai cosa? La prossima volta semplicemente non controllo e basta quasi quasi perché appunto ho le mie cose da fare è comprensibilissimo, comprensibilissimo e una delle ragioni per cui questa, una delle tante per cui questa cosa può capitare è che appunto si vanno a creare magari dipendenze fra i test appunto che non sono più autonomi ma magari interferiscono con lo state dell'altro, con i prerequisiti del test che deve venire dopo, capito? Io ti creo io test 1 ti creo l'utente per te test 2 funziona quando siamo, quando eseguiamo in maniera seriale quando andiamo a parallelizzare il test 2 parte per primo poi la cosa peggiore è che magari non è che fallisce sempre fallisce ogni tanto quando test 2 parte prima di test 1 in qualche modo, quindi aggiunge capito? un ennesimo grattacapo cioè il test che fallisce sempre in un qualche modo magari capito? Ti fermi, dici questo proprio non funziona lo metto in quarantena subito, lo fixo adesso tutti quegli errori invece che diventano che non succedono continuamente adesso mi sfugge la parola, sono intermittenti diciamo quelli creano più casino in un qualche modo secondo me sempre stare attenti, la mia indicazione di base è test autonomi, indipendenti e brevi cioè chiedersi sempre cosa devo testare qui qual è lo scope, sto aggiungendo roba e poi ci sono comunque, devo dire, i tool i tool di automazione offrono anche dei buoni metodi secondo me per andare a, che ne so, a isolare il setup da quello che è il test effettivo, no? e far girare quel setup, quella fase di preparazione per il test nel momento giusto, prima di ogni test prima di questi test, no? prima di solo questo test qui insomma c'è modo di configurare le cose in modo giusto, però bisogna pensarci bisogna investirci un po' di tempo perché altrimenti dopo partire male costa tanto, insomma vero, verissimo sai a cosa mi porta a pensare questa cosa? questa cosina che insomma ho appena fatto, ho appena evidenziato e che tu hai chiarito mi porta a fare un ragionamento magari mi sbaglio però tenetevi furti perché questa è una di quelle parentesi di Mauro e ne esce con cose che non c'entrano niente quindi abbiate pazienza, sopportatemi penso che dipenda proprio il fatto di fare dei test accoppiati l'uno all'altro e far esplodere tutto, una roba che poi ti dice no boh li tolgo viene un po' dal ragionamento dello sviluppatore dal modo in cui pensa lo sviluppatore dal modo in cui pensa il software engineer rispetto al modo in cui pensa il QA o il test engineer il software engineer pensa col behavior in mind ok? col comportamento in mind step by step è indispensabile invece per il test engineer chiarire lo scenario prima di tutto lo scenario nell'ottica dello sviluppatore puro un po' si perde, un po' si diluisce perché lo sviluppatore non tiene traccia in testa di tutti gli edge case possibili e immaginabili ma tiene prevalentemente traccia di quello che è il best case e cerca di tamponare se nel best case scenario trova dei lack ecco, quindi una cosa che e lo dico mettendomi in prima persona quando scrivo dei test io difficilmente cioè faccio fatica a immaginarmi tutti gli scenari possibili e immaginabili e invece la definizione chiara dello scenario quindi per capirci dello stato del database se vogliamo semplificare o fare un esempio dello stato del database a quel dato momento la chiarificazione di quell'elemento mi porta necessariamente a dire ok io devo inizializzare questo test a un certo stato inizializzarlo a un certo stato ti costringe in qualche modo a disaccopiarlo da tutto il resto perché stai partendo da un T0 ecco quindi probabilmente il fatto perché tutto questo ragionamento per dire che probabilmente il fatto di avere dei test accoppiati tra di loro dipendono non necessariamente dallo strumento che si usa per fare i test ma quanto dalla forma mentis che abbiamo nello scrivere i test per fare lo switch di cappello tra il test engineer e il software engineer è talvolta difficile cosa ne pensi? mi trovi anche qui completamente d'accordo mi sembra un buon ragionamento è anche una questione secondo me ha molto senso è una questione un po' di bias dati da quello che noi facciamo è chiaro che tu che lavori internamente alla soluzione al prodotto tu hai chiaramente un punto di vista completamente diverso mentre se io sono là fuori da lato diciamo io sono magari anche un QA engineer test automation engineer, quello che vuoi embedded in un team di sviluppatori però comunque la mia prospettiva come hai detto tu è diversa in un qualche modo parlare, provare anche a scambiarsi appunto come dici tu il cappello, provare a vivere un giorno ogni tanto diciamo nelle scarpe, nei panni dell'altro aiuta molto devo dire una delle cose di cui sono molto contento a Checkly che vedo che c'è questa il bello forse della startup in un qualche modo tutti hanno questo senso di ownership in un qualche modo e quindi vanno molto facile saltare fuori da quello che sarebbe appunto magari la propria posizione, il proprio day to day riesce molto facile questo tipo di esperimento questo tipo di comportamento magari quando, dico ipoteticamente quando si cresce si diventa anche un po' più rigidi tutta la struttura diventa un po' più rigida quei BIOS diventano ancora un po' più pericolosi sì sì sì sì esatto pensavo a un'altra feature perché ormai ci stiamo spostando all'interno delle feature una feature che tra l'altro potrebbe aprire un'altra di quelle parentesi enormi infinite però gli exporter dei test result una cosa che ho trovato molto figa di Playwright questo è un po' l'outcome della fase di discoveri dei miei colleghi che hanno perso un po' di giorni cercando di smontare Playwright e capire se in realtà l'upscaling che ha un certo costo dal punto di vista aziendale verso un nuovo tool era motivato e una cosa figa che ho trovato e che poi mi ha aperto una serie di ragionamenti è appunto l'exporting dei test result che è out of the box e in un po' di formati giusto? sì sì giusto sì l'exporter in sostanza è built in una delle cose come dire lì poi adesso non so quando è magari l'ultima volta che avete appunto fatto questa piccola investigation però, o più sì insomma però secondo me la cosa che sposta di più in quel senso lì è probabilmente il trace viewer cioè non solo io ho i test o il reporting che poi mi permetta di addentrarmi anche in ogni singolo test, test result ma per ogni singolo test result ho proprio la trace posso nel momento in cui quello fallisce posso davvero come dire spostare il mio cursore sulla timeline andare a vedere quali errori in console avevo quando abbiamo eseguito quel determinato comando e nei casi impestati è una cosa fondamentale aiuta tantissimo devo dire e anche io quando sono lì che magari guardo un test che conosco poco è di un cliente che mi ha chiesto una mano è una delle cose che hanno spostato di più secondo me che ha aggiunto più valore fra tutti i vari sviluppi recenti perché ti permette davvero con precisione pressoché chirurgica di andare a vedere che cosa è andato storto in uno specifico caso volevo chiederti una cosa che piace molto di Cypress è il test runner visuale c'è qualcosa del genere per playwright? sì nel senso c'è l'inspector diciamo che permette di ovviamente tu puoi metterti vari breakpoint per default playwright fa girare il browser in modalità headless quindi non vedi nulla ovviamente però tu puoi semplicemente far partire tutto in modalità head full e poi fare step through di ogni singola istruzione e anche quello è molto utile devo dire e ci sono tante cose che aiutano davvero tanto a capire effettivamente come stanno andando le cose c'è anche un'integrazione con via code fra l'altro che anche quella appunto, vedi Microsoft anche quella comunque aiuta molto a dare una developer experience che sia secondo me veramente ottimizzata io da sviluppatore sono già su via code ho il plugin, ho playwright test, tutto lì in codice che poi è una cosa che anche adesso a checklist stiamo provando in un qualche modo a replicare avendo anche noi il nostro tool CLI che ti permette di far girare quei test sia in locale ma anche poi trasformarli in check o monitor che girano di continuo sui checklist quindi secondo me adesso si qui mi sto un po' allontanando però secondo me quella è la direzione in cui andiamo everything has code in un qualche modo si si si vero, ritornando però agli exporter e poi alla fine all'output del test la buona parte dell'output dei test noi lo utilizziamo per andare a fissare bug andare a fare hotfixing andare a salvare la roba che va a fuoco però una roba ancora poco utilizzata in realtà dal mio punto di vista almeno in quello che mi è capitato di vedere in piccole, medie ed enormi aziende è un approccio un po' più manageriale al testing cioè ad oggi esiste tutto il mondo del test management che non sta emergendo ancora ma che è super interessante specie nell'ottica collegata al fatto che abbiamo dei tool come playwright che attraverso l'exporter ci danno una serie di informazioni faccio un esempio pensiamo a adesso mettiamo i panni del product manager pensiamo a come possiamo utilizzare i test ad oggi io sfido chiunque e lo chiedo anche a te quanti product manager conosci che danno un'occhiata alle test suite in development non al synthetic monitoring ma alle test suite in development? pochissimi pochissimi sì forse nessuno io mi dischiari un nessuno quando in realtà dal punto di vista di management quello che emerge sono tutta una serie di informazioni utilissimi da misurare faccio una serie di esempi una che hai come la defect density che ti permette di stabilire per ogni modulo la densità di difetti che le test suite trovano e questo ti permette di stabilire il costo di sviluppo di ogni modulo oppure defect leakage cioè quanti difetti fanno bubble up dalla test suite e arrivano all'utente per un certo modulo o per tutta l'applicazione questa roba è super interessante quello che secondo me manca in realtà è una semplice azione di comunicazione cioè una cosa che trovo probabilmente sviluppata in modo superficiale non so se per scelta o semplicemente perché manca questo tipo di prospettiva di questi tool Cypress, Selenium e Playwright è l'idea di passare un messaggio verso l'utilizzo di queste KPI cioè faccio un esempio lancio i miei test end to end un test end to end insiste su alcune parti di codebase io ho la possibilità per esempio essendo un tool mi verrebbe da dire vorrei avere la possibilità di evidenziarmi dove insiste il fallimento in quali moduli del software insiste il fallimento su questo secondo me c'è ancora tantissimo da fare adesso non so come in modo specifico, in modo pratico ci sarebbe magari da ragionare sopra però si aprono tutta una serie di prospettive che finora non sono battute cioè quelle dei framework di test management sì, sono d'accordo e guarda non penso di poterti dire tanto qui ma esattamente ho toccato qualche NDA no, no, non per quello però come dici tu nel senso di solito ci sono poi tool dedicati perché questo è come dire già da come l'hai messa tu si intuisce che è un argomento piuttosto vasto quindi almeno fino ad adesso come dire queste cose di solito non sono built in nei tool di automazione perché sono due mondi non so se in futuro le cose ti potranno cambiare però di solito ci sono sempre stati dei framework esterni per il test management per il reporting di quel tipo poi che ti permette di andare a in teoria almeno guardare alle metric di cui hai parlato tu io nella mia limitata esperienza mi è capitato molto raramente anche solo di come dire di sentire conversazioni utili di questo livello non sto dicendo che non siano conversazioni utili solo che come magari dicevi già tu magari dove siamo più indietro in generale come industry capito? cioè non siamo col fatto che c'è già tanta complessità proprio nell'automazione di per sé cioè a livello più basso andare a fare poi questo tipo di conversazione di livello più alto invece di in cui traduciamo tutto a livello di prodotto o magari di processo di sviluppo è difficile nel senso anche parlando anche con tante aziende grandi non c'era non c'era il focus non c'era magari la cultura lì è dove mi aspetterei capito? magari ottimisticamente che nei prossimi anni ci sia magari qualche qualche breakthrough no? e di solito anche quando sono andato a guardarmi a fare un po' di ricerca su questi argomenti ho sempre trovato tante risorse come dire almeno le risorse più disponibili capito? le cose che ti saltano ti saltano addosso dalla homepage di Google mi sono sempre sembrate un po' superficiali nel senso non ho trovato ancora cose illuminate su questo argomento diciamo secondo me perché siamo siamo un po' è presto semplicemente secondo me non c'è tanto know how sì sì magari il know how c'è anche però è un problema forse di silos che i due mondi non si parlano che i tool diversi non si parlano in modo aperto che vuol dire nel sito di playwright tra gli exporter no? magari c'è qualcosa di più pensato anche in questa direzione insomma sono degli scenario che io non vi nascondo che ho pensato anche a una start up per qualcosa del genere ma siccome ho 70.000 side project non ho paura a dirlo si aprono degli scenari si aprono dei mondi quello che però oggi con Giovanni possiamo confermare affermare che semplificando la dev experience i nostri team sono sempre più portati a testare testare è bene se è testato bene come si suol dire altrimenti diventa una grande perdita di tempo e poco affidabile e che comunque playwright è uno di quegli strumenti che in qualche modo proprio migliorando la dev experience ci porta a migliorare le nostre test suite fondamentalmente come sempre ragazzi io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare di soldi ma non vedo perché vergognarsi a una cosa così bella, parlare di soldi perché i soldi sono veramente la cosa più bella del mondo quindi donate perché dobbiamo fare una scena da massimo bottura con i vostri soldi quindi è una cosa molto importante e siamo molto poveri quindi donate copiosamente veramente in tantissimi mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare, ovvero metterli su delle crypto uscite da mezz'ora ogni volta che sento questa musichetta mi viene da ballare d'ansecchiare sul posto è il momento di ringraziare chi ci sostiene e visto che dal momento in cui abbiamo disattivato qualunque tipo di pubblicità in realtà le donazioni e gli acquisti referenziati su Amazon sono l'unico nostro modo di sostentamento dobbiamo ringraziare due amici che questa settimana ci sostengono e sono stati il motivo per cui siamo riusciti a uscire anche questa settimana il primo è Luigi Tacetta e il secondo è Giovanni Italiano che entrambi ci hanno donato una birra Luigi e Giovanni noi vi ringraziamo tantissimo per il supporto perché grazie a queste piccole donazioni noi possiamo pagare tutti gli abbonamenti e riuscire a essere online anche la prossima settimana e via discorrendo se vi fa piacere se in qualche modo Gitbar ha in qualche modo preso un posto nella vostra vita o vi ha apportato del valore vi prego supportateci per far sì che anche per altre persone potremo portare quel valore e continuare a portarlo anche per voi stessi detto questo io vi ringrazio infinitamente e vi ricordo che qualora non vi vada di fare una donazione o volete supportarci anche in altro modo potete andare in uno dei link delle note dell'episodio uno dei link di Amazon dove potete andare e si aprirà una sessione da lì potete comprare quello che volete possono essere uno spazzolino da denti o dei pannolini per la bimba e pochi centesimi del vostro acquisto andranno a supportare Gitbar noi vi ringraziamo e nuovamente tiriamo sui calici e brindiamo a Luigi e a Giovanni, grazie io ho visto ero un po' distratto adesso ho visto un attimo l'orologio siamo già a un'ora e un quarto e Giovanni mi ha detto che era distrutto ancora prima di registrare la puntata, io tipo sono un cadavere ambulante quindi voliamo rapidamente al momento il paese dei balocchi il momento in cui i nostri ascoltatori condividono qualcosa e ha catturato la loro attenzione e pensano che sia interessante condividere con noi quindi ti chiedo Giovanni hai qualcosa da condividere con la nostra community? e conduco nel paese dei balocchi ahhh il paese dei balocchi si non è direttamente ambito testing o nemmeno synthetic monitoring è più un articolo che mi ha dato da pensare più ampiamente sul sul web e sul nostro modo di consumare informazioni è un articolo che si chiama The Garden and the Stream, non so se lo conosci è abbastanza famoso ma ma lo devo essere perso in sostanza adesso la faccio molto come dire vi do il teaser magari mezzo teaser mezzo spoiler ma come dire ovviamente l'idea iniziale di web come ce l'avevamo magari negli anni 90 o inizio anni 2000 oggi quando navighiamo sul web abbiamo un'esperienza molto differente c'è il concetto il concetto magari più iniziale del web con ipertesti e collegamenti e come dire questa struttura che cresce e rimane di contenuto che rimane e viene costruito con la cura magari anche di un contenuto che deve rimanere in un qualche modo sta lasciando posto secondo me più allo stream in un qualche modo, qui sto già inserendo la mia opinione se guardiamo su youtube ad esempio nel senso il mio canale automate together che è piccolissimo ha pochi video e la maggior parte sono video molto specifici che vengono da un'idea specifica e magari di uno use case particolare di play write come che ne so l'automazione del two factor authentication cose che come dire ho incontrato con magari clienti o che persone mi hanno chiesto sai cosa ci starebbe a fare un bel video proprio targeted su questa cosa lo mettiamo lì ma perché ho avuto l'idea però se seguite un qualsiasi content creator che è un nome interessante su youtube o su una delle tante piattaforme non necessariamente video insomma piattaforme che fanno girare il web oggi il concetto è quello dello stream cioè il contenuto la piattaforma ti favorisce anche se tu pompi fuori contenuto continuamente devi avere questo stream engagement continuo che vuol dire produzione continua in un qualche modo e questo articolo parla un po' di questo di questo concetto qui e ve lo consiglio bello e si ricollega anche a quello che ho detto qualche episodio fa le mie i miei piani per l'anno nuovo che sto portando avanti davvero sono quelli di ridurre gli articoletti piccoli eliminare completamente le stories di instagram o i tweet e andare a leggere o libri o o paper o articoli cicciosi che magari ti portano via anche una buona mezz'ora 40 minuti per leggerli e rifletterci perché dobbiamo come Giovanni ci hai appena ricordato dobbiamo in qualche modo anche rimpadronirci del nostro tempo del tempo di fare le cose no? Ne parlavamo anche al Fosdem con gli altri e l'ha detto Alessio in modo molto chiaro, dobbiamo anche ridare un valore alla fatica nel fare le cose e il dedicare il giusto tempo è uguale anche al dedicare un effort, un impegno una certa fatica quindi mai articolo fu così ben tarato come quello che ci proponi oggi.

Io invece qua sulla scrivania mi son ritrovato avevo in mente un altro balocco però mi son ritrovato questi pochi foglietti che sono reduci da come ho svuotato la borsa dei gadget dei goodies del Fosdem il primo è un piccolo foglietto che mi ha dato un certo Ken Follon che è colui che tiene l'Hacker Public Network che è un aggregatore di podcast del mondo hacking, sviluppo software e in genere il sito è freeculturepodcast.org e ha una lista di podcast tutti in Creative Common e l'idea è quella appunto di...

e ce ne sono un sacco ce ne sono su Linux, ce ne sono sul Kernel ce ne sono sulla tecnologia in generale sullo sviluppo veramente ce ne è un gozziliardo buttateci un occhio, questo è molto figo, prima o poi anche Gitbar andrà a finire là dentro e poi per le, ahimè, ancora poche donne all'ascolto al Fosdem ho scoperto una cosa fighissima, che esistono delle community femminili tematiche e l'idea era appunto riuscire a individuare qualcosa di interessante che catturasse l'attenzione di mia moglie, voi sapete è una date engineer, e ho beccato una roba carina che si chiama Postgres Woman che è una community che ha come obiettivo insomma tutto il ragionamento della diversity nel mondo Postgres è una cosa curiosa se c'è qualche signora all'ascolto o comunque qualcuno interessato al mondo Postgres con lo sprint di lavorare verso un mondo un po' più diverse di quello che abbiamo adesso specie nel nostro ecosistema, ecco questa può essere una cosa interessante Giovanni, mi ha fatto superissimo piacere averti qua a fare questa nostra bellissima chiacchierata io ne approfitto per ricordare nuovamente il tuo canale Youtube, ci ho buttato un occhio, ho visto un paio di video carino quello che hai fatto su Amazon ha catturato la mia attenzione il canale Automate Together ricordiamo insomma che là ti possono trovare metteremo nelle note dell'episodio tutti i tuoi contatti per il resto grazie di nuovo grazie, grazie davvero grazie a te, è stato un piacere ringraziando nuovamente Giovanni io vi ricordo rapidamente i nostri contatti info.gitbar.it at BrainRepo su Twitter, ricordiamo che nel sito web c'è un link per supportarci e ci sono diversi modi per supportarci attraverso quel link dove potete fare una donazione e invitarci una birra oppure direttamente potete supportarci in modo indiretto direttamente in modo indiretto non si può sentire vabbè abbiate pazienza io ormai sono fuso, ma il modo per farlo è mettendoci delle belle stelline su l'aggregatore ApplePodcast e se ci ascoltate con Spotify o con Audible vi ricordo che esistono dei player molto migliori li trovate cercando New Podcast Apps su Google e trovate insomma dei player molto fighi, ce ne sono davvero un gozziliardo quindi buttateci un occhio tanta roba io vi do appuntamento alla prossima settimana e la prossima ciao.