Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qui nel nostro Gitbar.Siamo con noi oggi Leo, ciao Leo come va? Ciao a tutti, tutto bene.Ti vedi abbronzato? Sì, ho fatto qualche settimana al mare di vero smart working e mi è rimasta.Sono pronto per l'estate.chi se la spassa...è vero smartworking! Talmente smart che alla fine di working ne rimane poco così! Sshh siamo in problema! Ti ascoltano è vero non avrei dovuto dirlo fate finta di...non ho detto niente! Abbiamo anche un super ospite oggi che vi annuncio subito dopo avervi ricordato i nostri contatti infochiocciola@gitbar.it @brainrepo su x sono i nostri contati canonici poi c'è il c'è il tasto muto del microfono no il gruppo il gruppo telegram che trovate scrivendo gitbar su telegram siamo una 1500 e parliamo parliamo un po di tutto non so le cose si fanno negli ultimi giorni perché ho registrato molto però siamo lì ci potete raggiungere.Allora a questo punto io direi di far partire la sigla e poi presentare il nostro ospite.Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo ma ahimè lo stronzo è me medesimo e l'ho scritto giusto ieri.E mi dispiace.Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery, gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flake pure.Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei commit message prima di tutto, e dentro ce l'appella tutti i santi.Non bestemmi guarda.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che "non si può fare di default" diventa velocemente un "tutto è possibile" se hai le risorse, tempo e budget illimitato.Siamo noi quelli che l'AI va regolamentata, ma hai visto questo nuovo modello che disegna Ratti in Funambuli? Quelli che il "dipende" e "unisci gratis la prigione" e quelli che la RAL...no vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una mia illusione.Quelli che si sentano dire ho un'idea per un'app ed è subito l'ennesimo social come Instagram ma meglio.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo ai github e davanti a una birra tutto ci sembra un po' meno grave.Ed è così che inizia questo nuovo episodio di Gitbar ed è così che presentiamo l'ospite di oggi.Abbiamo infatti con noi Stefano Magni, front-end engineer a Preply, ex Asura, ne abbiamo parlato tantissimo sia di Preply che di Asura qua nel podcast.Erano entrambi dei balocchi.Interessante.E' esperto di front-end testing, di UI testing ed è per questo che ti abbiamo portato qua a insegnarci come si testa la UI perché in realtà il testing della UI è una di quelle cose che sembra facile e facile quando ci approcci, no? Però è anche facile farlo male.È vero, è verissimo.Molto più del back-end.Non sono esperto sul back-end ma sul front-end posso confermare che è facile farlo male, è vero.Anche per te Inga.Ciao a tutti e grazie per avermi invitato.Grazie a te per essere venuto qua appunto a trovarci.Io ho come punto di riferimento in realtà tutti i miei fallimenti.Io non sono mai stato in grado, e lo ammetto qua pubblicamente, di fare del testing UI fatto bene e la mia domanda proprio quella iniziale è esistono dei dogmi, dei punti fermi che ci possono guidare nella scelta delle strategie per fare front end testing? Allora se dovesse sceglierne uno solo perché ai miti di fallimenti ne ho passati tanti parte del motivo per cui oggi siamo qua a parlarne è perché ho fallito così tanto che ho detto "no, aspetta, forse adesso mi devo sedere e non è proprio così facile come me raccontavano, aspetta che mi siedo e cerco di studiare meglio".Se dovessi sceglierne uno solo, in termini di ritorno di investimento, direi che consiglio sempre testare le poche applicazioni frontend con uno strumento per i test end-to-end, Cypress, Playwright, quelli che volete, questi due sono i migliori.Quindi un test dove si testa, si apre il browser, si testa l'intera applicazione frontend, ma non c'è il backend reale, quindi non si parla di un test end-to-end, ma si parla di un test, ogni framework lo chiamiamo, un test di integrazione di UI, testo l'intero frontend senza il backend.Ovviamente posso anche spiegarvi perché do questo consiglio.Sei muto? A proposito di...Ah, immagino che vuole...che sia...sì, certo.Dici perché poi anche io che faccio parte più del back-end dico "Ma poi il back-end dove sta? Se il front-end ha bisogno di fare delle chiamate API?" Quindi andiamo.Direi che...allora, io non sono contro i test end-to-end, ma sono per avere pochi test end-to-end, solo alcuni che testano le funzionalità più importanti, solo gli fpbuff, quindi solo che una cosa funziona, non che una cosa se la faccio non funziona, se non funziona in un altro modo, se no non funziona in un altro modo, eccetera eccetera eccetera.Perché? Perché testare l'intero stack, seppur è fantastico perché i test end-to-end sono gli unici test che ci dicono se qualcosa è effettivo, se la nostra applicazione è tutto front-end e backend e funziona, sono troppo complicati da mantenere.Testano così tante cose che sono veramente troppe.Simulare alcune case d'uso è molto complesso.Immaginiamoci se noi abbiamo un e-commerce e vogliamo testare il flusso applicativo di cosa succede se l'utente ha messo un prodotto nel carrello, poi va per pagare, inserisce una carta di credito che è la carta di credito scaduta.Ora, se abbiamo un test end-to-end, quanto è complicato far questo perché ho bisogno di inizializzare lo stato applicativo del back-end in modo che quando il front-end richiederà i dati al back-end tramite le API, il back-end gli guarda che tu sei un utente, guarda che hai inserito questa carta di credito, ma questa carta di credito è scartata.Quante scorciatori ci servono nel back-end per creare lo stato applicativo di cui abbiamo bisogno, per questo caso d'uso? Troppe! È veramente troppo lungo.Possiamo scegliere mille approcci per implementarlo, ma alla fine è veramente complicato.Un'altra cosa, in genere, per la natura dei test end-to-end, che sono test in cui si carica un browser, si carica un'applicazione web, di solito questo tipo di test vengono completamente scaricati al front-ender, quando in realtà il front-ender è l'ultimo responsabile per tutto quella mole di dati e stato applicativo che deve creare nel back-end per poter testare il front-ender.Intendiamoci, stiamo testando tutto insieme, ma è veramente tanto, tanto, tanto complicato, test che sono molto lunghi da essere eseguiti, sono molto instabili, richiedono che per essere più veloci il backend esponga delle API, che sono delle scorciatoie di fatto, che però il backend non vuole esporre in produzione perché sarebbero scorciatoie molto pericolose, eccetera eccetera eccetera.Quindi dividiamo i due mondi, c'è il frontend e c'è il backend, soprattutto perché mi è anche capitato spesso volentieri che da un punto di vista backend è molto comodo che siano i frontender a testare il backend, perché di fatto vanno a testare solo ciò che serve al front-ender.Però ripeto, stiamo scaricando su front-ender il compito di testare il back-end, che è fuori dal loro controllo.Altra cosa, vuol dire che noi noi di fatto non possiamo neanche testare il front-end se il back-end non è pronto, perché se per caso il back-end viene implementato settimana prossima, ma io posso poter cominciare ad oggi a implementare il front-end, senza il back-end io quasi non posso fare niente.Essenzialmente, con "non posso fare niente" intendo dire non posso testare però c'è anche una pronta.In realtà non puoi nemmeno scrivere il front-end se non hai il backend pronto quindi non è solo una questione di test.Di solito magari se io sono pronto prima ti dico guarda Leo mi fa piacere so che tu non è ancora pronto il backend però a grosso modo mi dici quali saranno le response che vorresti dare magari tu in un paio d'ore riesci a darmene io sviluppo il mio front-end contro quelle response che sono dentro la mia codebase frontend, poi le elimino e aspetto quando sarà pronto anche il backend.Con questo approccio però io posso testare, posso non solo implementare il frontend ma potrei anche testarlo, dato che una volta che ho le response io uso queste response al posto del backend reale e posso implementare al 100% il mio frontend.Questi sono i tipi di test che nella mia personale esperienza mi hanno sempre dato un ritorno di investimento altissimo.Volevo farti una domanda intanto abbiamo parlato di responsabilità tra back-end front-end è una domanda bastardella è un po' provocatrice ma i testers proprio i QA dove li metteresti in questo processo? Dipende molto dal prodotto perché se parliamo di un mondo perfetto, io i QA quasi non li metterei.Nel senso che i QA come li intendiamo noi, come spesso si intendono purtroppo, sono persone che sono le uniche responsabili di controllare che l'applicazione funziona.Gli altri, i sviluppatori, se ne spartano, rilasciano quello che vogliono, tanto se si spacca lo controllerà qualcun altro.Questo è come di solito usiamo i QA, però questo non è dare valore QA, il valore QA è...guarda, noi sviluppatori abbiamo implementato e controllato che tutto funziona come previsto per i casi d'uso per i quali abbiamo implementato o aggiornato il software quindi, per quello che noi ci aspettiamo l'utente possa fare, noi siamo tranquilli tu fai un paio di controlli, però noi siamo tranquilli ora, cerca di spaccare il prodotto in modi che noi non ci aspettiamo minimamente Questo è "Exploratori Testing" e questo sarebbe il valore dei QA.Spesso volentieri, però, in realtà, come vengono usati i QA è "Ho finito il frontend, l'ho pubblicato, divertiti, e poi questi poveretti hanno bisogno di uno o due o tre giorni per andare a testare tutti i flussi, poi tornano da me, non funziona questo, ah, che qui, questo che non funziona!" È una cosa spesso volentieri, purtroppo, banale, che avrei potuto controllare da solo.se avessi avuto dei test automatici o se avessi fatto dei test un po' più approfonditi da me nel browser.Ok, ho aggiornato.Un giorno dopo, ho trovato un altro bug, aggiornato.Un giorno dopo, bug, aggiornato.E poi magari io come sviluppatore ho anche il coraggio di lamentarmi che i QA mi interrompono e non riesco più a lavorare, ma di chi è la colpa dei QA? Io è mia.La mia parere è mia.chiaro, chiarissimo pensavo anche un'altra cosa, però quando hai detto una parola che mi è rimasta impressa in mente mentre parlavi che è la parola flusso quindi posto che i QA appunto hanno il compito di fare forza brutta per trovare quelli che sono gli edge case che si rompono che difficilmente possono essere trovati in fase di sviluppo perché spesso quando si sviluppa si è troppo concentrati sugli epipath questo è un mea culpa da sviluppatore oppure in alcuni casi tanti prodotti che sono molto complessi è veramente difficile prevedere come romperli e secondo me si fugge anche da quello che uno sviluppatore può arrivare a prevedere quando magari un QA che lavora più con il reparto di prodotto ha più la visione degli utenti di prodotto sanno quello che loro fanno quindi sanno che magari sono i clienti che quasi sempre fanno delle cose che non sono propriamente canoniche e quindi hanno disfaccato il prodotto in maniera inaspettata per me.Però scusami se interrompo.No, no, no, assolutamente.Pensavo a un fatto che a questo punto una volta che abbiamo definito le responsabilità del QA ci sono io frontender che devo sviluppare la mia suite di test no e ho fondamentalmente due elementi che mi si presentano davanti la prima sono gli user journey e la seconda passatemi il termine non preciso sono le schermate cioè quelle schermate statiche che sono quelle appunto non non ci sono flow complessi.Come si approcciano a questi due tipi di UI? Partiamo dalle schiamate statiche che sono tra virgolette più facili.Allora quando noi automatizziamo i test, di solito quando si parla di scrivere test automatici si parla di scrivere un test che interagisce con la pagina, con quale strumento a quale livello poco importa.Una Una pagina statica, se non ha nessuna interazione con l'utente, è difficile che andremo a riscrivere dei test complessi, nel senso che potremmo non scrivere test automatici nel caso che abbiamo, o che integriamo, dei visual regression test, cioè la pagina statica deve semplicemente essere così, con questi colori, con questi testi, eccetera eccetera.Fare uno screenshot e controllare che rimanga sempre tale.Questi sono test che testano la parte di CSS e di HTML in genere, non la parte di JavaScript per la quale ci serve interagire con la pagina.E anche la parte di accessibilità, che HTML, CSS e accessibilità fanno sempre parte di tutti i test, però quando si interagisce invece con le pagine che sono più complesse, in quel caso la parte di CSS, HTML e accessibilità...Accessibilità no, ma CSS e HTML sicuramente viene un pochino meno.cosa intendo, conviene un pochino meno, intendo dire che è difficile che noi testiamo sempre tutto in ogni test, cioè una perplessità che spesso c'è con i test è "ah cavolo ma io vorrei scrivere "ho il test che funziona in Chrome, adesso voglio che il test venga lanciato anche in Firefox, anche in Safari, anche in Edge, anche in Appianato".In realtà questa è la perplessità che si ha quando si comincia a fare i test di solito, ma appena si comincia a farli e si acquisisce un po' di esperienza, è difficile che questa capacità rimane tale.Perché? Perché se io ho una suite di test che impiega 30 minuti o 15 minuti parallelizzati per essere eseguiti su Chrome, perché devo testarla anche su Firefox quando magari la grossa differenza tra i due non è probabilmente nel funzionamento del lato perché grazie al nostro webpack, Vite, SWC di turno, la parte JavaScript viene convertita in modo che funziona sui browser.Le differenze CSS, quindi, non si trovano con dei test automatizzati dove interagiscono con la pagina, ma si ottiene facendo degli screenshot della pagina utilizzando servizi da pagamento, cosa che io consiglio, che renderizzano la stessa pagina in diversi Tornando sulla parte di javascript, una pagina complessa è lì che ci interessa usare Cypress WebWrite per andare a interagire molto con la pagina e nel caso in cui il backend reale, il backend non c'è, perché noi stiamo usando delle response statiche al posto del backend, diventa anche molto facile testare i casi d'uso, cosa succede se l'utente non è nato prima, cosa succede se server mi dice che l'utente era già registrato? cosa succede se l'utente mi dice che il tuo backend di autenticazione non è più valido e va a riaggiornare? eccetera eccetera eccetera nel momento in cui non c'è il backend reale, simulare questi casi è facile perché il frontend di solito è un'applicazione stupida chiede le cose importanti al backend e il backend gliele dà nel momento in cui andiamo a usare delle resposte statiche al posto del backend possiamo testare praticamente tutto nel frontend non è sempre così facile ovviamente perché non voglio farla estremamente facile facile, però sono dei test che mi hanno sempre dato un maggiore tonno di investimento.Quindi, prendendo la prima parte di questo discorso, quando dicevi "non si va a testare con dei test automatici, diciamo con Cypress o Playwright, il CSS", vuol dire che io dico "cercami il form, metti questo valore e clicca", poi se ci sono 12 pixel di margine non lo vuoi vedere la funzionalità, quello semmai me lo dice uno di questi tutti che magari dopo lo troverò.Esattamente, nella maggior parte dei casi, se noi non avessimo il CSS e la nostra applicazione è bianca col Times New Roman e bottoni greggi, di solito gli automation tests scritti con Playwright e Cybers passano.Poi quella pagina è pronta da vedere, ma funziona.Certo, hanno un altro scopo, o meglio, non usiamoli per vedere che il titolo è sopra il sottotitolo, quello si guarda da un'altra parte.Sì, lo consiglio vivamente di non fare questi tipi di test, perché è uno dei motivi per cui poi i test nel tempo li si odia, perché oggi li scrivo, passano, domani passano, dopo domani cominciano a non passare.Perché non è passato? Perché ho cambiato la classe CSS dell'elemento però la colpa non è di chi ha cambiato la classe, ma di chi è il furbo che ha collegato i test a delle classi CSS.Le classi CSS hanno uno scopo, i test hanno un altro scopo, non vanno mischiati essenzialmente, perché sennò capita troppo spesso di avere test che falliscono.Però vedo la tua faccia per quello che hai detto in domanda.No, no, no, chiedevo, quindi anche un test che dice controlla questo elemento che abbia questa classe CSS in realtà non è così utile perché magari chi chi cambia la classe non è il front-end, è il designer e quindi diciamo al front-end ingeniere non interessa come si viene visualizzata l'applicazione.Facciamola facile, uno dei motivi principali, uno dei tanti motivi principali per cui i test falliscono e poi quindi abbiamo un'esperienza negativa e poi li odiamo e poi li cancelliamo e poi pensiamo di aver buttato via il nostro tempo è che noi tendiamo a testare le nostre applicazioni front-end o anche applicazioni generali ma soprattutto front-end perché la mia esperienza, come se fossimo dei programmatori.Cosa intendo dire? Chi è che in una pagina è in grado di controllare? Vediamo dal punto di vista dell'utente.Qual è l'utente che è in grado di controllare che ci sia una classe CSS in pagina? Un programmatore, sicuramente non l'utente finale.Chi è l'utente che è in grado di trovare un campo di input basato su un attributo speciale che si chiama test_id? Sicuramente non l'utente, il programmatore.Però nel momento in cui noi testiamo le nostre applicazioni come programmatori, noi stiamo andando a testare i dettagli implementativi Perché una classe CSS è un dettaglio implementativo Poi, di solito la domanda che sorge è "Sì, no, ma aspetta, ma io non ho altro modo per capire se il bottone è rosso se non controllando la classe CSS" Il mio risposto è "Vabbè, perché tu devi controllare che il bottone sia rosso?" In un test automatico in cui controlli l'interazione con la pagina controllare è, tu vuoi controllare, vuoi mantenere, vuoi fare uno screenshot test, uno screenshot test in cui si trasforma la pagina intera in una png e si controlla che questa png non cambia nel tempo, però è separato dal interagisco con la pagina essenzialmente.Noi oggi sviluppiamo il frontend utilizzando dei framework moderni, no? E voglio collegarmi a quello che hai appena detto nel senso che se voglio testare come viene visualizzata la cosa faccio utilizzo una tecnica specifica che appunto il visual regression o questo tipo di approcci e quindi io se potessi venire da te ti abbraccerei perché questo vuol dire non più snapshot testing che non servono a niente e che sono difficili da mantenere quindi sentiti abbracciato virtualmente.Però pensavo anche a un'altra cosa, ci sono degli stati, allora se io sto testando la pagina della sua globalità ci sono degli stati che sono difficili da raggiungere perché sono stati intermedi come il nostro buon amico Davide Di Pumpo ci insegna con qualunque componente almeno tre stati, caricamento, stato base che potremmo chiamare così e errore, questi sono minimi.Ci sono alcuni di questi stati che si possono raggiungere attraverso dei flow a meno che non testo unitariamente quello specifico componente e a quel punto posso isolare, posso interagire con lo stato perché magari ho un componente, un container per cui riesco a isolare la logica dalla parte di visualizzazione.Fatta questa premessa, quello che in realtà mi interessava capire con te è come cavolo li testo questi stati intermedi se volessi fare un visual regression testing nella sua interezza non lo faccio? Hai detto giusto "nella sua interezza" perché voglio sottolineare questo? Perché scrivere test per le nostre applicazioni vuol dire scegliere cosa testare ma soprattutto cosa non testare, cioè è difficile che noi abbiamo dei test che testano veramente tutto e direi anche che non è per forza consigliato.Non trovo per forza indispensabile che in tutti i form io testo che quando faccio submit il botone e scompare il testo c'è il loading ad esempio.Ovviamente dipende dall'applicazione, da tante cose dipende, però Se tu vuoi testare tutti i visual regression tests dei tre stati del componente, l'environment ideale è Storybook per questo, dove tu hai un catalogo con tutti i stati del tuo componente e fai un visual regression test sui stati del componente, così tu sai che da un punto di vista stilistico i componenti non cambiano come si mostrano.Questo però richiede anche che il storybook può essere usato per molte cose.Può essere usato semplicemente per "toh, metto lì una storia del componente così che sai che il componente esiste e ci puoi giocare" oppure può essere usato come mezzo di comunicazione e confronto con il team di prodotto perchè a quel punto io non ti metto lì solo il playground per giocare col bottone ma io ti metto una storia per ogni singolo stato del componente In questo modo tu sai cosa io prevedo che il componente possa fare e cosa no.Possono anche fare dei visualisation test su ogni singola storia.Con questo non voglio dire che se non c'è storia in Book 1 non riesci a testare la propria applicazione.Però dipende dalla dimensione dell'applicazione, da quanti componenti abbiamo, dagli stati, dalla complessità, l'obiettivo comunque non è mai per forza infilare tutto dentro SciPy, ma soprattutto dentro BraveWrite.Diversi tipi di test hanno diversi casi di uso, anche lo snapshot testing che hai menzionato, ho scritto tanti articoli e anche uno proprio sullo snapshot test, è una strategia di testing che a me non piace, ma non è che non mi piace per sé, non mi piace perché è diventata troppo diffusa rispetto all'utilità che ha, perché ha un'utilità lo snapshot testing, che serve per 3 o 4 è molto utile in 2 o 3 o 4 casi d'uso, mentre adesso è un po' strassano di moda, però è esploso e praticamente per qualsiasi cosa di frontend si usa lo snapshot testing.Perché è una shortcut.Esatto.Ma tu stai scaricando sul prossimo la tua non voglia di scrivere test come si deve e solo che il codice lo scrivi una volta, lo refactori 10 volte e lo leggi 100 volte.Quindi quando tu scrivi codice per chi devi scriverlo? per chi lo ha fatto e per chi lo legge, non per te.Ho una domanda, magari non tutti sanno che cos'è Storybook, io l'ho usato da backend ingegnere forse solo come catalogo, in 10 secondi dimmi se ho capito.Storybook è un'applicazione React nel quale io all'interno posso scrivere i miei componenti singolarmente, quindi con i vari stati, quindi il bottone non cliccato, il bottone cliccato, eccetera.E mi si presenta come appunto un catalogo organizzato come voglio io però di tutti i miei componenti, però io l'ho usato appunto come catalogo, come per dire "guarda, abbiamo creato questa dialog box, ti fa vedere il codice con cui implementarlo, però com'è che viene usato per il testing?" L'ho letto un po' nei tuoi articoli, ho detto Ah, hai detto tutto giusto, toglierei solo la parola React da quello che è Storybook, nel senso che sì è vero Storybook è sviluppato con React, ma non c'entra la framework usata in Storybook con la framework che possiamo usare noi.Quindi Storybook è semplicemente un sito fatto apposta per essere un banalissimo catalogo di componenti, dove noi andiamo a dire "guarda, ho il mio bottone, avrei piacere di aggiungermi una storia con il bottone normale, il bottone mentre scarica, il bottone quando è disabilitato, il tooltip, il form, il campo di input.Quindi mi trovo un catalogo dei miei componenti, essenzialmente.Quindi sì, è giusto, è una galleria di stati dei nostri componenti.Come si aggiunge il testing a Storybook? Allora, la cosa più facile da fare in assoluto è Storybook è mantenuto da Chromatic.Chromatic chi è? L'azienda che fa soldi con Storybook.loro danno Storybook gratis a tutti e offre una developer experience talmente comoda che sì c'è qualche alternativa a Storybook ma non ha quasi mai senso usarla.Sto un pochino esagerando ovviamente perché c'è senso però nel mazza 5% dei casi vai tritato su Storybook, lo conoscono tutti i frontender, tutti lo usano al mondo.Chromatic ci appende sopra dei servizi a pagamento.Quali sono i servizi a pagamento? Sono la build di Storybook stesso, quindi non non ti deve preoccupare, ci agganci Chromatic e loro te lo buildano, te lo rendono disponibile in cloud, ci attaccano il visual regression testing, quindi loro senza che tu fai niente, ti trovi il tuo componente con tutte le storie, con tutti gli stati, testato in tutti i browser, e loro ti allertano se qualcosa cambia.In più, di recente, di recente ormai si parla dei due o tre anni hanno aggiunto anche una parte di interaction testing, ossia dentro storybook loro hanno mischiato testing library con playwright ed essenzialmente tu quando crei una storia per un componente, che è giusto per tutti, una storia di un componente è semplicemente un componente visualizzato in uno stato specifico, puoi creare una storia interagisci come faresti un test classico con il tuo end, interagisci con il tuo componente e poi alla fine controlli che niente sia fallito essenzialmente.Quindi automaticamente ti trovi un sito che è una galleria dei tuoi componenti.Visual Regression Test, se vuoi, test anche di interazione con i tuoi componenti.La developer experience è fantastica.Poi bisogna vedere se uno decide di avere un lock-in così forte come Storybook e spingere i propri test dentro Storybook.Ma questo è un altro discorso.Storybook offre una developer experience fantastica e sì può essere usata per fare test.Ok, confermo la developer experience perché essendo un back-end ingegner l'ho usato per alcune parti in cui mi sono occupato del front-end e non ho avuto grossi problemi nel capire come funzionava.Mi mancavano poi alcune parti, però è fantastico.Si, si, si, si, confermo.E poi la cosa bella è che tutti lo conoscono.Cioè, se tu assumi un frontender o qualcuno che ha scritto mezzo componente, sicuramente è passato anche tramite Storybook.Oppure lo fai come domanda "Interview, conosci Storybook?" "No"."Ok, grazie." Esatto.E c'è qualcuno che è anche bestemmiato per farlo funzionare bene? Purtroppo la cosa brutta di Storybook è che si deve avere un'esperienza fantastica ma si possa dire che ci sono parecchie dipendenze cicciute.Se uno può capitare che se si lavora in progetti e sono la maggior parte, le dipendenze non sono state mantenute proprio aggiornatissime, è facile che ci si trovi a fare front and doors e bestemmiare collegando le diverse dipendenze.Presente.Presente, perché qua ci siamo passati tutti.Ti volevo fare una cosa, ti volevo fare una domanda, perché se prima hai detto una cosa l'hai detta quasi sottovoce, hai droppato la bomba sottovoce, no? detto non è tanto scegliere cosa testare ma è importante decidere cosa non testare e questa cosa non mi è sfuggita e a questo punto ti chiedo siccome mi son trovato in quella situazione ti chiedo come posizioni l'asticella nel senso qual è la tua le domande che ti fai per decidere questo va nella lista delle cose da testare e questo invece facciamo finta di niente? La risposta semplice è stai facendo fatica a testarlo? Sì, allora non è da testare.Partiamo dalla risposta semplice, semplice, semplice.Però c'è anche da fare secondo me due cosi distinguibili.Uno è se stiamo testando la nostra applicazione, perché noi adesso stiamo parlando di test solo di test end to end, cioè carico l'intera applicazione frontend.Quando io parlo di test, man mano che si diventa esperto, quando io faccio i miei corsi a conferenze, a aziende, io insegno sempre a partire dai test end-to-end e i test di integrazione di UI, quindi browser, frontend intero e senza backend.Ma quando uno poi ci prende di mestichezza, capisci che ci sono altri test che hanno un grosso valore e pian piano cominci ad esplorarli, quindi quando io parlo di testing non parlo per forza sto ritestando.Seconda cosa, i test, la maggior parte di noi lavora su applicativi che non hanno test e quindi si trova ad aggiungerli in corsa, essenzialmente.Questo è uno dei casi di uso dello scrivere test.Ma parliamo un attimino del mondo ideale.Io sto sviluppando qualcosa di nuovo, sto implementando una feature nuova e in concomitanza scrivo i test.I test testano l'applicazione e testano il codice.Cosa intendo dire? Un test in two-hand testa l'applicazione.Ad esempio, durante i miei corsi io spesso faccio gli esempi in cui io vado a testare un'applicazione React, ma alla fine io switcho dall'applicazione React all'applicazione Vue, i miei test passano.Perché quando scriviamo dei test in two-hand fatti bene, interagiamo con l'applicazione e testiamo l'applicazione, ma è il codice.Però, se si scende nella piramide dei test, ci sono tanti test che sono più legati strettamente al testare il codice.Quando si trova a testare il codice, qual è lo scoglio che incontri? Noi non ce ne rendiamo conto, perché di solito si parte sempre a testare con gli unit test, però si fa fatica, non funzionano, e devo muccare quel modulo, è instabile, è un casino, li odio.Il problema è che la maggior parte delle volte i nostri test non funzionano perché il nostro codice fa schifo, ma noi, tutti noi, io compreso, non parti dal presupposto che il tuo codice fa schifo, perché pensi che funziona, perché fa schifo, funziona.Chi se ne frega se non è modulare, design, architettura, funziona, sì, allora perché non riesco a testarlo? Eh no, questo è uno dei problemi.Quando si cerca di testare il codice, perché a un certo punto, quando l'applicazione diventa grossa, i test end-to-end o i test integrazione di UI dove usi il browser intero cominciano ad essere poco pratici, perché immaginatevi una pagina con una tabella, una tabella che ha magari, dove tu puoi fare il sorting delle colonne, puoi filtrare, puoi aggiungere elementi, sono talmente tanti i casi di uso che non è molto pratico che tu quella pagina con la tabella la testi con 20 minuti di test nel browser.è facile che tu testi la tua tabella in isolamento, ma la tabella è talmente grossa che è facile che le funzioni più importanti, la business logic di questa tabella, la vai a testare in isolamento con degli unit tests.Se tu hai progettato e architettato il tuo codice bene, riuscirai a testarlo facilmente.che a quel punto se tu hai fatto una progettazione vera della feature che stai implementando è facile che ti ritrovi che hai dei test a macchia, quindi sì, ho dei test che testano un'intera feature, ma è facile che hai anche un po' di unit test, un po' di unit test di componenti dove tu decidi dove metterli, ma siccome tu l'hai progettato e sai come vai a testare se no il 20% di quello che fai.Il resto dici ok se funzionano queste parti chiave della mia funzionalità io sono abbastanza certo che funziona, non me lo garantisce nessuno, ma io sono abbastanza certo.Però questo viene da forte progettazione del codice, forte progettazione della funzionalità e anche uso ottimale di tutti gli strumenti di Static Analysis, TypeScript.Se usato bene bene bene bene aggiunge una solidità fortissima al tuo codice e quando hai quella solidità offerta da TypeScript.Per i codici che non è così importante testarlo, ma non perché TypeScript ti rimuove i test, perché a un certo punto vai in giro per la tua funzionalità e vedi che il codice è talmente semplice, talmente dritto, è talmente comprensibile e fa talmente poche cose, perché in genere il codice che scriviamo, anche se non vogliamo, fa 100 cose anche quando non serve, che a volte dici ma perché questo devo testarlo? Perché questo devo testarlo? Questo sì, questo no, questo no, questo no, e questo dipende però anche talmente dal fatto che hai progettato quello che stai facendo perché se l'hai progettato bene ti trovi che hai di solito le parti più piccole, i componenti più piccoli, che sono molto stupidi e non esistono nel multitest, bravate in componenti altrettanto stupidi, vi abbracciate i componenti abbastanza smart, quindi magari testi questo, quello smart, vi abbracciate un componente stupido, vi abbracciate un componente stupido, vi abbracciate un componente smart, vi abbracciate una pagina.Quindi, test in tuo end per l'applicazione della pagina, qualche test di componenti, qualche unitest, e sei contento così.Ovviamente se in alcuni casi è utile che si lascia anche scritto cosa non hai testato e perché.Così almeno il prossimo disgraziato che si troverà a guardare la mia codebase chiama "perché non le ha scritte questi test.Se lo scrivo io, ok? Scusa, pensavo una cosa mentre parlavi, no? Il fatto che noi alla fine riusciamo a, e io sono uno di questi, a coprire la nostra applicazione con i test a macchia di leopardo che però poi alla fine grosso modo riescono, proprio con l'approccio a layer che dicevi, grosso modo riesco a coprire quasi tutto, avere una coverage alla fine dei giochi abbastanza alta perché magari ho delle business logic specifiche che voglio veramente verificare che si comportino esattamente come si devono comportare e ci sono degli altri posti dove il massimo che si può rompere è un pixel che ha uno shift di 3 un bottone c'è uno shift di tre pixel e lo testo col visual regression e anche se non lo testo non muore nessuno, quasi, a meno che non vada nascosto dalla cookie policy.Però mi chiedo esistono, perché mi sembra di non averne mai visto, dei tool da quanto, se li hai mai incrociati nella tua esperienza di tool che riescono a caricare, a calcolare in modo statico la code coverage crossando questo tipo di test quindi end to end unit test magari anche integration test.Allora io non l'ho mai fatto ma sono tanti anni che su playwright non sono sicuro che si possa fare ma sono sicuro che si possa fare su Cypress, perché Gleb Amurov, che era nel team di Cypress, che è uno che ha rilasciato migliaia di librerie e scritto un sacco di articoli sull'uso avanzato di Cypress, ha pubblicato altri articoli su come estrarre il code coverage dell'applicazione intera da Cypress e come andarlo a mergiare con code coverage che arrivano da altri strumenti di test, come Jest ad esempio.Quindi si può fare.E questo è interessante perché alla fine è una metrica che ci dice ok forse dobbiamo coprire più questa zona che è un po'… se ne vale la pena a livello di business perché poi magari quel test non genera valore di business.Cioè una volta che si diventa anziani diciamocelo pure, va bene tutto quello che la letteratura dice va bene tutto quello che qualche personaggio in stile Uncle Bob ha detto, però alla fine è zitto.Con i vecchi come Uncle Bob bisogna fare così, non riesco più a togliere la clip è infettivo no però scherzi a parte alla fine alla fine bisogna anche essere pragmatici perché noi siamo pagati per generare valore il valore che diamo facendo i test è avere un minimo non di garanzia ma un po più di fiducia in quello che rilasciamo e aver la possibilità di andare veloci quando rilasciamo delle nuove feature senza preoccuparci troppo di rompere tutto.Se questo vallone non viene generato a questo punto mi viene da dire probabilmente non ha gran che senso aumentare la coverage.Io di solito non mi tocco della coverage onestamente.A mio parere la coverage è usata come Allora, il coverage è usato come strumento per capire cosa ho testato ma soprattutto come dicevo prima cosa non ho testato, quindi il coverage lo posso usare per dire "cavolo, secondo me questo caso d'uso, questo flusso è molto importante, lo dovrei testare" e lo scrivo in destra.Poi il coverage lo butto via, mi serviva solo per capire se ho dimenticato qualcosa.A mio parere il coverage è usato come metrica, che in genere si può tenere un concetto più obiettivo ha veramente poco senso, perché è troppo facile falsificare una metrica come il coverage.Io posso scrivere un test che non testa niente ma con un coverage molto alto e voi direte "sì, ok, però si fa sempre questo esempio, ma poi nella realtà concreta perché devi fare una roba del genere?" Non è vero, infatti io non è che farei mai apposta a scrivere un test che non testa niente ma con un coverage, però il risultato è è che io magari scrivo test che per inesperienza testano poco o testano male, ma siccome il coverage è alto io penso di aver scritto dei buoni test.Questa è una falsa confidenza in quello che tu hai fatto.Per questo che dico sinceramente il coverage non lo misuro e non lo consiglio.Ovviamente se noi stiamo scrivendo una libreria open source usata da un sacco di persone, dove in genere la libreria open source, non è che stiamo sempre parlando di librerie che hanno della UI stiamo parlando di solito di funzioni, ok, magari molto complesse, fanno cose esagerate ma sempre funzioni stiamo parlando allora, quello è diverso, perché se una libreria open source è usata da duemila persone mi interessa che sia testata fino all'ultimo punto percentuale quella libreria ma in un progetto normale, in un prodotto, io non sono un grande fan dell'utilizzare il cover edge onestamente Sì è vero il coverage è una bussola, una mappa più che altro, anche perché se il coverage viene...anche se devo dire che spesso in ambienti enterprise il coverage è una roba che ti dice sì o no per farti passare la rola delle pipeline.Io non ho mai lavorato in ambienti di Enterprise, cioè ho lavorato su prodotti giganteschi, molto complessi, ma mai in ambito Enterprise, dove mi viene richiesta un tacco di coverage.Se io, dimenticandomi per un attimo la questione di Enterprise, per me ha molto più valore una descrizione della pull request molto dettagliata e lunga che mi spiega cosa tu vuoi fare, e poi do un'occhiata ai test, poi do un'occhiata ai codici, rispetto al coverage in sé.TDD scrivi prima i test e poi il codice funziona in ambito front-end? Non lo faccio mai, nemmeno l'ho fatto forse l'unico per cento delle volte, ma perché il TDD in sé non è niente di male, il TDD è un'ottima pratica, il problema a mio parere è che il TDD è facile da dire ma difficile da fare, cioè per riuscire a fare TDD concretamente sul front-end a mio parere è il Devi lavorare in un contesto di flusso, di prodotto, di professionisti che ti permettono di fare TDD.Non posso pensare di fare TDD se ogni giorno mi cambiano le specifiche e il cambiare ogni giorno le specifiche non è una cosa che succede una volta di tanto, ma succede spesso.Quindi secondo me è il contesto che mi permette di fare TDD.Poi, la mia parola TDD ovviamente è impraticabile quando devi fare qualcosa che non conosci esattamente come si fa, però di solito non è il caso principale.Sicuramente quello che io di solito insegno nei miei corsi, perché di solito ho insegnato anche a senior e anche a gente che già è senior nel testare, ma principalmente insegno a junior o middle in ambito testo, il mio consiglio è dimenticatevi del TDD.Se qualcuno vi viene a dire che se se non fai TDD non testi, grazie mi stai dicendo non fare TDD, ripeto non è il TDD che ha qualcosa di male, ma uno non può pensare di fare TDD se non è già esperto con i test, devi essere esperto, devi lavorare in un contesto giusto, già abbiamo ridotto del 98% le aziende e i prodotti su cui si può lavorare per usare TDD.A mio parere il titolo in ambito frontend non è una cosa fondamentale.Quello che io di solito insegno è usare lo strumento di testo come strumento di sviluppo.Cosa intendo dire? Siamo abituati a scrivere codice per tre giorni e ogni volta scrivo un pezzo di codice e vado nel browser controllo che va.Pezzo di codice, apro il browser.Pezzo di codice, apro il browser.Pezzo di codice, apro il browser.Per tre giorni.Arrivo alla fine e dico "Ah, fantastico, finito, adesso devo scrivere i test" Leggo un'altra giornata solo per scrivere i test Scrivere i test è molto importante ma ha sempre un costo in termini di tempo Quello che io consiglio è parzialmente di assorbire questo costo nello sviluppo Cosa intendo dire? E qui tendo sempre a sostituire "non sto parlando di TDD" Quello che sto parlando è Scrivo un pezzo di codice Invece che aprire il browser e interagire con la pagina scrivo un pezzo di test che fa in automatico quello che starei per fare io manualmente nel browser scrivo un pezzo di codice, scrivo un pezzo di test, pezzo di codice, pezzo di test pezzo di codice che ti gestisce un edge case, copio e incollo il test e controllo l'edge case altro edge case, scrivo un altro test alla fine di tutto questo flusso, apro il browser e manualmente controllo che non funziona qual è la cosa interessante a mio parere? che prima di tutto io non arrivo alla fine e ho la noia di dove scrivere i test, perché a dettaglio ciò che necessitiamo per scrivere i test è noioso.Cioè il nostro cervello ha deciso che è già finito quando dobbiamo scrivere i test.Altra cosa, lo strumento di test è uno strumento che fa le stesse azioni che noi faremo manualmente ma le fa molto più velocemente di noi, quindi io parzialmente risparmio tempo perché i mille test manuali che farei in 2-3 giorni, mi rifarò lo strumento di test che è molto più veloce di me.Questo però non è TTT, non scrivo prima il test e poi scrivo l'applicazione, scrivo un pezzo di codice e intanto in parallelo scrivo il test.Questo è il mio consiglio come frontender, ovviamente sempre parlando di test nel browser dove il backend non c'è.Anche perché in realtà se utilizzassimo l'approccio che ci siamo detti prima dove copriamo l'applicazione ma con layer diversi di test diventa spesso anche difficile farli a head of time scrivere a head of time il test end to end o il test di integrazione.Però io non voglio dire non voglio parlare male del TDD io non lo uso ecco secondo me è difficile usare io non lo uso No, io vedi, io lo riesco a usare, lo uso con piacere quando faccio back-end.Allora sì, ho le mie belle funzioni atomiche, però là sto testando solo un elemento specifico che è behavoring, no? Certo.Sto testando dei comportamenti.Il test front-end ha tante altre sfumature che in realtà sono più difficili da far entrare nel meccanismo del TDD.Comunque lasciamo aperto un thread all'interno del nostro gruppo Telegram se qualcuno non è d'accordo, se qualcuno vuole inforzare questo concetto, vi prego condividete le vostre opinioni là.Abbiamo detto che scrivere i test a head of time potrebbe essere complicato se non impossibile in ambito front-end in alcuni contesti.A questo punto c'è un altro approccio, specie quando abbiamo già terminato di scrivere l'applicazione o il componente o chi per lui, cioè il fatto di c'è un bug a questo punto potrebbe aver senso mi scrivo il test che mi evidenzia il bug e lo vado a fissare questo però in realtà genera un problema di fondo che è la stratificazione dei test cosa cosa voglio dire prima tu hai detto testo un edge case copia e in colla modifico altro edge case coppia in colla modifico altro edge case coppia in colla modifico altro edge case e annegano un mare di merda dopo perché lo devo andare a modificare come gestisco questa situazione? Sei pronto ad essere annoiato da me per i prossimi 45 minuti su questo argomento? Allora parto da un presupposto e non sto parlando di test stavo parlando di codici di prodotto.Noi come programmatori tendiamo a sottostimare il costo della strazione e a sovrastimare il costo della duplicazione.Tendo a sottolineare che non voglio dire che uno non deve mai scrivere una strazione e deve sempre duplicare i codici, però quello che noi come programmatori secondo me spesso sbagliamo è "ah, ho scritto due volte la stessa riga di codici, bah, una funzione, lo astrago", "ah, ho usato due volte la stessa "ah, faccio un'altra estrazione che mi nasconde il fatto che ho duplicato un codice" perché la conseguenza di questo di solito è che si schimano estrazioni troppo presto queste estrazioni poi di solito non le togliamo cioè quando quelle estrazioni ci sono poi le tieni e continui ad aggiungere if, if, if, if e a un certo punto ti trovi con un codice che è impossibile da comprendere che fa tre cose stupidissime, ma ha sette funzioni, che le fa, sette funzioni chiamate a catena, una stata peggio dell'altra, con dentro 14 if l'una.E non capisci più cosa fa il codice, anche perché tu di solito non sei quello che l'ha scritto, sei quello che non l'ha scritto, ma anche tu fra 3 giorni ti dimentichi cosa faceva.Con questa premessa.Ah, ovviamente invece la duplicazione del codice basta un find and replace per sistemarlo, Ripeto, non voglio dire mai astrazione, è sempre l'obbligazione.Il trade-off? C'è un trade-off, ma noi come programmatori siamo sempre orientati a fare astrazione.Chiudo il capitolo sul codice di prodotto.Il codice di prodotto ha una complessità, diciamo, 100.Ok? Noi scriviamo dei test automatici perché? Perché quella complessità 100 è troppo elevata, io non posso pensare di testare il mio intero prodotto manualmente.Quindi scrivo dei test automatici perché è così complesso, non mi servono test automatici.Se io scrivo di test che hanno complessità 94, quando il prodotto ha complessità 100, il codice di prodotto con complessità 100, che io ritengo incomprensibile, perché non avrei bisogno di test se fossi in grado di traversarlo leggendo quello che faccio, ok? Se poi mi trovo un test che ha complessità 94, sono compracapo perché mi trovo con un altro software che è impossibile da leggere.Dov'è che voglio arrivare? Voglio arrivare al fatto che, da mia esperienza, la complessità dei test e la strazione dei test è uno dei problemi principali per cui i test poi vengono cancellati.Cosa intendo dire? Ho tre test che fanno bene o male le stesse operazioni.Scrivo una strazione che mi astrae il tutto, ci metto dentro un paio di if e sono a posto.Adesso, finalmente, ho tre test che fanno due cose ciascuno.fantastici, guarda che bel codice che ho scritto, sono il programmatore migliore del mondo complimenti, appena fatto sì che nessuno sarà in grado di lavorare sui test per sempre e quando questi falliranno, perché falliranno, qualcuno spenderà una giornata intera a sistemarli da dove è che voglio arrivare? i test devono, e questo per me è imprescindibile, devono essere facilissimi deve essere facilissimo comprendere cosa fa il test questo non vuol dire che il test non può avere una situazione ma sicuramente il test non, non, non può avere un if nel codice, da nessuna parte.Se mi fallisce un test in CI, di solito capita che non è il mio che è fallito, ma c'è un test che fallisce, vediamo cosa fa.Devo essere in grado di partire dall'inizio e arrivare alla fine del test, anche spostandomi in diversi file, intendiamoci, ma non devo trovare nessuna if condition, perché se trovo un if leggendo il codice del test, a me viene il dubbio.Aspetta, questo non è un test, sono due test.Cos'è? In quale branch sono entrato? La CI, in quale branch è entrata? Per farvi capire quale test è fallito? Ok, e non è per niente facile perché a quel punto devo andare a cercare di capire quali sono le variabili d'ambiente che usa la CI per cercare di replicare, di seguire il flusso nel codice che sto leggendo.Ma se io ho ho degli if, è molto facile perché ho tante astrazioni, tanti if, tante astrazioni parametriche io mi trovo con 74 flussi diversi in un singolo test in bocca al lupo capire qual è la combinazione che non ha funzionato in ci, dove è che voglio arrivare? se hai tre test che fanno le stesse identiche cose, lasciali lì, lasciali lì, duplicati, ti fanno schifo perché sono programmatore e ti fanno schifo, è il motivo per cui devi lasciarle lì.Quando arrivi ad averne 10 che fanno le stesse cose, va bene allora astrae il codice.Però con "astrae il codice" non intendo dire una funzione che in base a quattro flag booleane decidono cosa fare nel tuo test e poi tu controlli il tuo risultato.Con "astrare" intendo scrivi non una funzione grossa, ma scrivi 10 funzioni piccole che magari astraggono solo una o due righe di test che non le stanno stanno strendo, stanno sollevitando e tu fai copia e incollamento.Queste funzioni non quasi mai devono accettare parametri, perché io devo poter essere in grado di leggerlo e capire tutto quello che succede senza fare difficoltà.È più facile da dire che da vedere, se ho davanti un esempio è più facile da raccontare.Quello che voglio arrivare è, non preoccupiamoci se il test ha codice duplicato, perché il il codice duplicato è molto molto molto facile ad essere compreso.L'unica regola che devi tenere a mente è che se tu tocchi una rega, fai un cerca nel progetto per controllare se quella rega nel progetto dei test è utilizzata da altre parti ed eventualmente la cambia anche di rega.Questo è il mio suggerimento.Ho visto, scusa, a riguardo, avevo letto oggi pomeriggio un articolo scritto da te dove appunto parlavi di questo, dove rendevi leggibile, facevi vedere i test della virtual list se non sbaglio.Esattamente.Prima il codice non leggibile, poi quello dopo e dici "ah".Io addirittura alla fine, erano 4 step, alla fine sono andato solo a vedere il codice, la differenza del codice.Poi ho letto un colpo, ma si vede proprio anche se il test è complesso, si vede come si può scrivere in una maniera leggibile.In più mi ricorderò di non mettere mai "if" nei test, non so se l'ho fatto, però ci stavo pensando prima.Ovvio, mai mai mai.e me lo tengo come warning, la prossima volta che scrivo "if" guardo se sono in un file di test o no.Esatto.Lo metti nell'inting della CI proprio.Se stai scrivendo un "if" la cosa più facile che tu stai facendo è che stai testando una funzione che permette di fare tante cose.L'esempio classico che ho citato anche in uno dei miei articoli è immaginatevi che la vostra applicazione ha una notifica, ok? Una notifica che viene fuori quando l'utente fa qualcosa.notifica di solito ha un titolo, un testo e dei bottoni.Naturalmente come programmatore ci viene da creare una funzione testNotification che accetta title, description, array di bottoni (opzionale) e dentro nella funzione facciamo un sacco di if e facciamo anche un for perché dobbiamo lovare sull'array.Un for e un if hanno la stessa complessità, né più né meno.No, non facciamo una funzione solo anche testo notifica, facciamo una.Test success notification, test error notification, test click on notification, test click on close test, queste funzioni saranno tutte stupide, non contengono if e tu decidi quale usare in base al test che stai facendo.Comunque si, tu hai preso l'articolo giusto che ho scritto perché calco la mano su questo argomento perché mi è capitato una volta, quando stavo ormai già da un po' che insegnavo in teoria e ero già l'esperto dei test, ho deciso di aggiungere anche la parte di component test ai miei corsi.Ok, visto che avevo appena scritto il mio applicativo, ho detto "Tiriamo dentro questo componente una virtual list, o anche i jest già fatti per il mio lavoro, c'è la lista".Bella lì.Il tiro dentro e salta fuori che io non riesco a capire cosa fanno i test.Perché non riesco a capire cosa fanno i test? Carivo, li ho scritti io sei mesi prima e in teoria io sono l'esperto dei test.Perché non riesco a leggerli? Non riesco a leggerli perché erano a strappi.Perché avevano dei if, avevano dei for, quindi il loro codice.Erano magari solo cinque righe, ma capire cosa facevano quelle cinque righe non era per niente ovvio.Quindi ho diviso quel singolo test che testava tre cose in tanti test verticali, tutti stupidi, tutti con dati statici, non dinamici, dove non c'erano for e non c'erano if.Salta fuori che ho scritto 10 test di una banalità impressionante, ovviamente come programmatore mi viene da dire "ma cavolo, ma sono 10 test che fanno quasi tutte le stesse cose!" Sì, ma quello che li leggerà capirà benissimo cosa sta succedendo, e se questi 10 test di due falliranno è in grado di sistemarlo in un secondo.O perlomeno, il test, grazie alla sua stupidità, sarà in grado di spiegare meglio cos'è che non sta funzionando.Non so posso a questo punto farti un'ennesima domanda bastarda? Come ti poni davanti a test.each describe.each? Nel senso che io ho più user journey che bene o male condividono più o meno lo stesso flow ma i comportamenti sono guidati da dei parametri in ingresso.Vedi questi...quindi step back e spieghiamo bene che cos'è perché forse alcuni amici non li conoscono.È un modo per descrivere le fixture in ingresso o comunque una serie di parametri, fare un test parametrico dove io passo una serie di casi e il test itera questi casi ed esegue caso per caso.Generazione dinamica dei test.Esatto, come ti poni tu davanti a questa a questo approccio? Lo vedi come more complexity o lo vedi come Nel caso che tu hai specificato mi ci pongo male, nel senso che il test each ha lo stesso problema di avere un for o un if dentro al test, cioè il codice del test non è palpabile, è tutto astratto.A mio parere dov'è che funziona? Il caso d'uso che tu hai menzionato però è "ho un flusso utente le cui interazioni sono simili o uguali" sei ancora da noi perché non vedo più...Sì sì ci sono, ci sono.ho un flusso utente in cui le iterazioni dipendono dai parametri dell'ingresso ecco questo a mio parere è proprio il motivo per cui tu non dovresti avere una generazione dinamica dei test in questo caso perché rendono troppo complesso quando uno di questi test fallisce capire cosa non ha funzionato.Dov'è che a mio parere funziona il test Il test_each funziona quando hai una funzione, non un componente, una funzione e veramente tu vuoi semplicemente bombardarla con input diversi, ma una funzione sincrona a cui passo dei parametri e mi dà uno o due più parametri in uscita, dove non ha nessun valore se io vado ad escrivere "quando passo 1 a questa funzione ricevo 2", "quando passo 2 ricevo 4, quando passo 4 ricevo 8, ma non ha nessun valore.A più valore si rimette un test IC di quadra.Questi sono i parametri di ingresso, 1, 2, 4, 8, questo in uscita, 2, 8, 16, 32.Ho fatto i calcoli ma ci siamo capiti.- Vabbè ti fallisce il test all'epedro.- Bravissimo.Quando io sto semplicemente bombardando la funzione con diversi input e ha un output, allora sì.Però se io ho però vuol dire che io prendo gli input, glieli passo, mi danno al tutto controllo.Questo è il test, quindi sono due righe di test.Nel caso invece in cui, come dicevi tu, interagisco, quindi le righe del test non sono due, ma sono tre, quattro, cinque, sei, allora lo vedo male perché, ripeto, sarà veramente difficile per il poveretto cercare di sistemarlo, isolare il caso che fallisce, leggere il codice del test che è di suonatura dinamico perché non c'è niente di statico, completamente dinamico, andare a lavorarci.Quando andare a lavorarci intendo dire che magari ci stupita 45 minuti di tempo quando un test stupido senza leach con un minuto, due minuti, cinque minuti, dieci minuti l'avrebbe sistemato.Sì, io da questo punto di vista penso, la penso in modo un po' diverso, nel senso che io lo useri anche per i componenti sempre se il flow del test è lineare quindi non ha branch condizionali perché nel caso abbia dei branch condizionali a quel punto è un altro test come abbiamo detto prima e sono d'accordissimo però fondamentalmente anche se devo testare un componente ci sono degli input ben definiti e un output un expectation ben definita a quel punto lo uso consapevole del fatto che qualche povero Cristo dovrà andare a commentare gli altri 4, 5, 10 linee di casi d'uso nell'array che gli passo come parametro a mettere un only da qualche parte per isolare la cosa.Prima di farti una domanda però butto in un'altra cosa di solito i test each non per forza ma di solito non sono tipizzati, gli input e l'output non sono tipizzati con questo è un problema gigantesco, perchè i dati di input e output che tu usi per testare la navigazione invecchieranno nel momento in cui tu cambi le proprie delle componenti, ma il test non ti dirà mai "guarda che gli input e output che ho non sono più validi da un punto di vista dei tipi".L'invecchiamento degli input e degli output su qualsiasi tipo di test è un problema gigantesco, ma giocando, anche quando io dico "testiamo il frontend senza il back-end", sì, ma le response statiche non sono dei JSON, sono degli oggetti JavaScript con una tipizzazione forte, non sto parlando di ES di TypeScript, non sto parlando di ES-Const, non sto parlando di TS-Ignore, non sto parlando di TS-Expectero, sto parlando di tipizzazione forte e i tipi vengono importati dal frontend.Nel tuo caso il test-each lo puoi tipizzare, ma la maggior parte delle volte non ambienti pizzato, quindi tu aggiungi il componente e il test lo dimentichi, fra sei mesi aggiungi il componente, si spacca il test e salta fuori che sono sei mesi che il test va con degli inputs sbagliati.Però a parte questo, la domanda che ti volevo fare è, mi fai un esempio pratico, ma non è provocatorio la domanda, mi fai un esempio pratico concreto che ti capitato dove usi il testitch per testare dei componenti? Sono due anni che faccio back-end quindi...Allora mettiamola così, perché poi...Però un'idea potrebbe essere il classico, cosa ne so, behavior del click che apre una modale con tre text message diversi a seconda del parametro, non lo so, sto inventando.A mio parere, se ti capita una roba del genere, stai testando troppe cose insieme, a mio parere, perché con una tipizzazione molto forte, in teoria tu dovresti trovare che la tua modale ha dei dati in ingresso ben definiti, il tuo bottone ha dei dati che passano con il back di onclick ben definiti e questi combaciano, vanno d'accordo tra di loro.Quindi perché devi testare un flusso del genere? Poi lo so benissimo che questo è solo un esempio.L'esempio a cui io vorrei contoribattere è se tu stai testando 50 combinazioni di input diversi contro un componente che renderizza qualcosa con JSX, quindi diventa HTML, diventa CSS diventa quello che vuoi.Mi viene da pensare che la trasformazione di quegli input in un output non dovrebbe stare nel JSX, dovrebbe stare in un custom hook di React o dovrebbe stare in una funzione vaniglia JavaScript che è isolata dal componente, quindi il componente diventa stupidissimo.Il componente riceve gli input, gli passa una funzione, dalla funzione riceve l'output e stampa l'output.Se no il componente si usulta in questo modo.Io non testo 50 combinazioni di input contro il componente, ma li testo contro la funzione.Perché tu stai dicendo che quel componente è la parte smart, se devi testare il componente con 50 combinazioni di input, ma la parte smart del componente non dovrebbe stare nel componente.E da qui che arrivo alla questione di progettazione.Perché se hai un componente di 100 righe dove fa tanta roba javascript ci sono un paio di custom hook e poi un JSX io lo tocchiamo per ridere perché una volta un mio collega l'ha chiamato così e il tuo JSX non è JSX ma un template HTML che vuol dire che hai tan...il JSX sono 150 righe pieno di condizioni if, loop, map, doppio punto di domanda, doppio percent, quello non non è JSX, quello è in temperatura HTML che sono due cose diverse.In JSX i componenti, come le funzioni, devono essere chiari, devono fare poche cose.E se tu lo soluti in questo modo, va a finire che tu non avrai bisogno del componente per testare le combinazioni di 50 input.Fai uno unitest sulla funzione.Il componente è stupido, prende gli input, passa la funzione e ne riceve di stampa qualcosa.Testa la funzione, non il componente, che è 50 volte più veloce da essere eseguito.chiaro? chiaro.ovviamente bisogna vedere degli esempi e intendiamoci.io in questo momento non riesco bene a dividere la mia parte back-ender e front-ender e quindi componente e funzione in questa fase della mia vita non hanno una grande differenza quando in realtà ce l'hanno Diciamo che il componente alla fine genera HTML, facciamola facile, so che non è l'argomento giusto, ma facciamola facile.Genera HTML.Perché tu hai bisogno dell'HTML per controllare cosa viene fatto nei tuoi input? Ripeto, il componente è stupido.Chiama una funzione, la logica è tutta in quella funzione.Magari sono 100 righe di colce, ma sono in quella funzione.Allora io testo la funzione, poi io prendo il colce del componente, lo guardo e dico ah, riceve le prof, le passa fuori alla funzione, riceve un output, stampa nel JSX l'output e cosa c'è da testare con un code così semplice? la complessità nella funzione ripeto, la sto facendo sempre facile eh si si, poi in realtà le sfumature sono un milione però io adesso a questo punto rincalzo facendoti un'altra domanda e la domanda riguarda sempre il godziliardo di input che io devo passare passare perché devo testare nmila casi.Se non uso leach come garantisco la consistenza nei flow di testing per tutti quegli use case? Detto in un'altra lingua come faccio quando Devo scrivere test e sono anche un po' distratto perché ho la DHD e mi rompe un po' le balle scrivere test.Lo so che siete tutti bravissimi, li scrivete tutti benissimo, siete super concentrati.Quando scrivete test sto parlando di me e solo me, però come faccio a rendere consistente quel flow su tutti i casi se devo andare col copy and copy? soprattutto come faccio a tenere l'attenzione alta quando lo faccio? Lo dico perché mi sono ritrovato spesso a vedere dei mostri proprio per questo tipo di problema.Chiaro.Allora, la risposta è un po' da stonzo.Sarebbe, se devi passare veramente un miliardo di dati, mi sa che stiamo testando un po' troppo ad alto livello quello che vogliamo testare.Però, questa è la risposta da stonzo.perché la risposta vera è che ci sono un sacco di casi in cui serve quel miliardo di dati.Ora, secondo me il problema non è il miliardo di dati, perché quel miliardo di dati te li puoi far generare te li puoi generare dal backend reale, la cosa più importante è che siano fortissimamente tipizzati.Nel momento in cui tu hai un miliardo di dati, io direi "ma se il tuo flusso serve un miliardo di dati, dobbiamo darglieli, non possiamo fare niente di diverso, è noioso".Ma la cosa importante, io so che avere un miliardo di dati è noioso, ma se non possiamo farci niente, non possiamo farci niente.Quello che però consiglio ancora è, mi raccomando, quel miliardo di dati che ti ha richiesto Mauro 4 ore solo per averli quei dati, perché un po' li avete, perché non potete inventarli un po', è un delirio.Mi raccomando, fai si che nessuno li possa smaccare.intendo, devono essere fortissimamente tipizzati, perchè quello che si tende a fare nei test è "ok, questo oggetto, as login server response" (vi dico una stupidata eh) "as" che viene sempre...che sono le type assertions di TypeScript, come se fosse il casting anche se non è un vero casting, è il modo migliore, e viene usato sempre nei test, per dire a TypeScript "guarda, taci, so io quello che sto facendo, tu non mi sei abito niente adesso è proprio l'errore più grosso dei test.La mia risposta un po' evasiva è "e se ti servono un miliardo di dati non puoi farci niente" però mi raccomando devono essere fortissimamente utilizzati già che fai fatica a scriverli se per caso cambia qualcosa a livello di TypeScript prima ancora che il test parta la CIT deve dire "occhio qui c'è un errore di TypeScript la fixed track che stai utilizzando per i tuoi test non è più valida.Aggiornala.Non sai quante volte in Asura, ad esempio, sono arrivato dopo un anno di lavoro a dire "Ragazzi, a causa di questo, questo, questo, questo, questo e queste best practices applicate ai test, che dopo un anno che non full time ma ci lavoro un po', li carceliamo tutti.Tutti.Se vogliamo ripartiamo da zero secondo le best practices.Se no, meglio non averne che avere questi, perché stanno solo rompendo le scatole.Però quando hai un oggetto customer che ha tipo...4.000 properties...- E devi testare ne solo 4...- È il tuo dominio, cosa ci puoi fare? E devi testare ne solo 4 la tentazione di "as customer" dietro l'angolo...Però...allora, sempre per fare un po' lo stronzo...Ma se devi testare ne solo 4...Perché stai testando qua, all'inizio della catena dei codici e non qua dove vengono ricevute quelle 4? Ovviamente l'altro risposto potrebbe essere "eh no, stai guardando che non fare il brillante, quei codici non lo scrivo io" Quindi non è proprio terminato testare quelle 4, hai ragione, ma la soluzione non è scrivere un test che ha neanche un miliardo per testare le 4 La soluzione in teoria sarebbe andare a scrivere un test che ne testa 4, rifattorando la parte che ci interessa.Oppure scrivo un test con un miliardo di dati così io so che perlomeno non posso sfaccare l'app.Poi vado a fare un piccolo rifatto, isolo questa parte che ne riceve solo 4, gli passo quelle 4, faccio il test con 4, ho rifattorato, quello principale funziona, sì, perfetto.Magari uso quello principale come cartina tronno solo, solo per controllare che non si spacca niente però di sicuro non mi aspetto che il miliardo di dati necessari per fare un test sia necessario per testare tutti gli edge case.Quello è un happy path e uso uno solo perché il fatto che servono un miliardo di dati per testare una combinazione di pochissimi dati vuol dire che allora non c'è una reale strutturazione del codice, vuol dire che ci sono magari due tre mac componenti che fanno l'era di dio.Giusto? A questo punto posso garantire la consistenza tra l'utilizzo parziale dell'oggetto globale e l'oggetto completo attraverso semplicemente i tipi e usando PIC potrei in questo caso.Si si si poi tu se preferisci usare PIC o preferisci scrivere i tipi o preferisci quello che vuoi però con tipizzazione molto forte e con design del codice migliore salta fuori che ti servono meno test e i test che ti servono sono meno complessi A questo punto la domanda brucia pello, come le gestisci? Le gestisci tu le fixtures, quindi i dati di prova, perché io ho un nego fisso nei dati di prova, in questo caso nel back-end, però devono essere verticali per ogni singolo testo, cioè non condivisi tra testi diversi, cioè se alcuni servono che siano comuni va va bene, ma è importante che tutti sappiano quanto comuni sono.Cosa intendo dire? Mi è capitato una volta dove io ho usato la fixta di signup sia per la signup che per la login.Tanto era la stessa, voglio dire i dati sono gli stessi perché chi se ne frega.Faccio un passaggio di consegno in un altro frontender e mi trovo che una delle sue domande è "cioè lui non capiva perché la login utilizzava la fixta di signup".e c'ha ragione, perchè diamine io sto utilizzando la fixa da sign up per la login avrei dovuto occuparmi di due diverse una login, una sign up, quindi gli stessi dati o avrei dovuto utilizzare una generica ma poi assegnare due variabili diverse avrei dovuto spiegare al lettore che quelle fixa erano una di login, una di sign up anche se di fortuna avevano lo stesso identico per loro per me le fixa devono essere fortissimamente utilizzate verticali per i test che mi hanno bisogno o è facile capire chi dipende da quale fixture.Cosa voglio dire per facile capire? Io, se ho una fixture usata in centro test, devo essere in grado, utilizzando le funzionalità di VS Code, per esempio di IntelliJ, che mi fanno capire quali sono i moduli che dipendono da questa fixture, devo capire quali sono i test che potrei spaccare se cambio una fixture, ad esempio.Poi, la cosa che di solito si tende a fare è "eh ma io c'ho una fixture gigantesca, no dai ne uso una per tutti" ma, o facciamo così, fanne una gigantesca a un tuo customer e poi, in una maniera molto prevedibile e comprensibile, prendi quella fixture, gli ne cambi un pezzo e questa fixture è pronta per un altro test, perché sennò tu ti trovi poi a dover modificare la fixture gigantesca per simulare gli edge case dei singoli test e allora non è più così comune quella fixtar.La fixtar quindi deve essere statica, a mio parere per la fixtar va allo stesso discorso di prima delle funzioni, non c'è una funzione che genera le fixtar, le fixtar sono statiche, e piuttosto sono duplicate.Noioso, ma piuttosto sono duplicate.La cosa bella della duplicazione è che se io cambio una fixtar in modo errato per un test, spacco un test e non ne spacco 100.che di solito poi non è prevedibile, ma perché ha toccato l'id dell'utente in quell'oggetto e la pagina di settings non funziona più? Perché? Eh, questo perché stiamo usando una fixta per fare i test.Il nostro superottimo soddisfatto.Sì sì, ci sta.E i tipi devono essere importati dall'applicazione frontend, perché è l'applicazione frontend che comanda...se poi addirittura i tipi non vengono da frontend ma vengono dallo schema generato dal server allora siamo a livello di perfezione però perlomeno devono essere utilizzati ecco e poi scopri che l'architetto quei tipi si li ha inventati perché gli mancavano ancora le specifiche dei servizi sottostanti benvenuti nel mondo enterprise Una cosa che capita spesso è che ad esempio si tende a tipizzare, ma la maggior parte delle volte i tipi vengono creati dai front-ender.La cosa che spesso capita è che i front-ender creano tipi per tutto ciò che il backend prevede, quando il front-ender bisogna dare la metà dei dati.Se un API restituisce 20 dati ma al front-ender servono 10, il tipo per il front-end ne ha solo 10, gli altri 10 non esistono.Poi, posso lasciare un commento dicendo "guarda, date a vedervi qui lo swagger, perché di dati ce ne sono in più, ma quel tipo ne ha solo 10".A mio parere è sempre importante vedere le cose dal punto di vista del frontend.Se le cose sono per il frontend, sono dal punto di vista del frontend.Se il backend mi dà un API sola, ma che fa 10 cose, io non ho una maxifunzione frontend che accetta 10.000 parametri e chiama l'API del server.Io ho 10 funzioni front-end, una per ogni singola API dal punto di vista del front-end, anche se poi sotto sotto stiamo sempre parlando del stesso endpoint server.Però anche qui entriamo in un altro capitolo che non si parla più di test.Chiarissimo.Domanda Leo, hai qualche domanda? No, avevo solo una considerazione che mi è venuta leggendo i suoi articoli, che mi ha ha cambiato un po' la prospettiva dello scrivere i test come se fosse documentazione, mentre spesso io scrivo i test per fare vedere la funzionalità e vedere se funziona in quella maniera, invece avendo in mente che questa roba la può leggere qualcun altro, è come un lascito che fa parte della documentazione e questa cosa si trasluda anche dai discorsi che fa Stefano ed è molto interessante, insomma, magari da domani di scrivere in un'altra Era una cosa a cui non avevo fatto caso.Sì, ci sta.Secondo me non è ovvio come passaggio.E anche io, ripeto, quello che insegno io sono i problemi in cui mi sono scontrato.Di solito il valore che la gente mi riconosce nei miei corsi è che io insegno un po' lo strumento.Tanto le best practice, tantissimo le bad practice.Cioè tutti i problemi che io mi sono scontrato, tutti gli errori che ho fatto io in prima persona, ve li racconto così che voi, che non state ancora testando, stanno a pieno successo, ve li tolgo.Sono ostacoli che vi tolgo dalla vostra strada.Farete comunque fatica perché comunque l'ambito testing è un ambito abbastanza difficile, ma almeno vi tolgo un po' gli ostacoli.Chiaro? Chiarissimo.No lies, need money for beers è il nostro momento per ringraziare chi ci supporta, chi si fa carico di alcune delle nostre spese di mantenimento e fa sì che quasi ogni settimana questo periodo, ma vi prometto che riprendiamo a essere costanti.Possiamo arrivare alle vostre orecchie.Abbiamo due donatori questa settimana.Abbiamo Marco Pettolicchio che ci dona quattro birre scrivendo "siete molto bravi Smile", grazie, il merito è tutto dei nostri guest e dei miei co-host e abbiamo anche Dario Zanotto che ci dona tre birre.Grazie per supportarci e per insomma farsi che appunto Gitbar possa essere registrato e possa arrivare ai vostri client di podcast.Ricordiamo che Gitbar ancora prima di essere un podcast è una community e quando si parla di community si parla di un effort condiviso che non deve essere necessariamente economico.Poco importa, la cosa più importante è appunto la condivisione di forze ed è per questo che le regole del podcasting 2.0 dicono che sì, ci può essere un supporto economico che può passare tramite Paypal o tramite le modalità del podcasting 2.0 con dei client avanzati che streamano Satoshi verso di noi, ma il vero supporto del podcast avviene attraverso le 3T Time Talent Treasure.Se abbiamo già parlato del Treasure rimane Time Talent per cui se avete del tempo e sono sicuro che avete anche tanto talento potete contattarci perché per esempio abbiamo il sito che insomma in qualche modo ha bisogno di una mano visto che come diceva Stefano prima non ci sono componenti ci sono i template HTML su quel sito ASTRO.Come dicevi tu bisogna generare valore, l'obiettivo è scrivere codici a fine a se stesso.In realtà quello che vorremmo fare siccome sono praticamente quasi allineato con gli episodi per le trascrizioni è mettere appunto bene il sistema di ricerca all'interno delle trascrizioni che appunto può generare valore ci sono un altro paio di cosine da fare per cui se avete del tempo libero e non sapete cosa fare ecco dare una darci una mano a intrattenervi può essere un modo veramente proficuo per occupare quelle domeniche pomeriggio mentre piove, ah no siamo quasi d'estate non piove più.Il talent comunque potrebbe anche essere il parlare dietro al microfono quindi se qualcuno si vuole proporre per parlare di qualcosa è tutto modo per fare nuove puntate, proporre nuovi contenuti quindi c'è anche quello.Assolutamente sì e mea colpa non averlo detto prima e grazie grazie Leo per aver proprio evidenziato questa cosa io spesso la do per scontata ma è veramente importante visto che Gitbar è un bar e chiunque avvicinandosi al bancone se ha qualcosa di interessante da condividere la condividono con la nostra community quindi se avete qualche topic in particolare condividetele condividetelo pure detto questo io direi che possiamo andare direttamente a questo punto al nostro paese dei balocchi."Riconduco nel paese dei balocchi" "Ah il paese dei balocchi" Il paese dei balocchi è quel momento in cui condividiamo con la nostra community un libro, un talk, un articolo, qualsiasi cosa abbia catturato la vostra attenzione e pensiate possa valere essere appunto condiviso con la nostra community.Io questa settimana non ho un balocco però sono sicuro che Leo e il nostro super ospite Stefano ne hanno uno quindi iniziamo da Stefano.Stefano cosa ti piacerebbe condividere con la nostra community? Allora uno dei miei libri preferiti è "The Art of Readable il codice leggibile è una tematica che mi interessa molto perché il codice lo scriviamo una volta, lo fattoriamo 10 volte e lo leggiamo 100 volte, quindi deve essere molto leggibile e comprensibile.Quindi è un libro che consiglio.Se dovessi consigliare altre risorse, io per fare un po' di campanilismo consiglio un'ottima newsletter che ho scelto, che è quella di Duca Rossi, che ha pagamento ma anche tanti contenuti gratis e comunque vale appena pagarlo.Consiglio la newsletter di Wes Khao, scritto WPSKHAO, che a mio parere sono tematiche più sul soft skill e la politica aziendale, ma sono tematiche a mio parere molto interessanti per crescere come ingegnere.E anche Frontend at Scale di Maxi Ferreira, una delle mie newsletter preferite.Direi questo, a parte la tonnellata di articoli ho scritto che mi aspettano tutti a andare a leggere.Confermo l'ultima parte perché me ne sono letto qualcuno, oggi è stato molto interessante.Io ho un piccolo balocchino, è stato uno dei miei ultimi acquisti, che sembra banale ma ora vi spiego, sono due pannetti di microfibra.Quelle di Apple? 25 euro l'uno? No, non sono di Apple, ma sono molto utili per il mio MacBook, perché sono capitato su un thread di Reddit, mi sembra, dove praticamente alcuni MacBook hanno questo problema che il grasso, tutto il sudice rilasciato dalle dita sulla tastiera, quando il MacBook è chiuso, va sullo schermo e non va più via, e anzi va a modificare, cioè rovina lo schermo, quindi se ce l'hai fuori garanzia, non lo puoi cambiare, tutto per fare roba super piccola.ho comprato questi pannetti, uno da mettere nella tastiera e l'altro, lo tengo nello zaino, per proteggere la tastiera quando è chiuso, visto che io lo porto chiuso per la maggior parte del tempo.Però fa pensare come una roba che costa diverse migliaia di euro abbia questi problemi.E Apple continua a mettere l'adesivo dentro le confezioni dei computer, che non si usa più, che è anche l'unico adesivo che uno non può mettere dietro il MacBook, perché c'è già il logo, scusate il rent e potrebbe invece aggiungere questa roba 15 euro e risolvere il problema, anche se ammetterebbe che c'è un problema, cosa che stesso non può fare, fine del rent.E non te lo venderebbe a 25 euro o quanto cacchio costa.No.E' fantastico, io i pannetti li prendo perché ho sempre visto quei quadrati sullo schermo e mi innervosivano fisso e se questa è la soluzione la sposo.C'è chi non li riesce a togliere perché c'è qualcosa che fa immacchiano lo schermo dietro fondamentalmente perché stanno in pressione perché magari qualcuno...Ti fai mettere in assorbito il casso.Sì, infatti.Quindi ho visto delle foto e ho detto no, non voglio...Arrivarli.Apple potrebbe dire che il bug sta in te, che hai troppo grasso nei polpastrelli.Dovresti pulirti le dita prima di scrivere, ogni volta.No, io ho mentito in realtà, io ho un balocco, però volevo appunto dirlo per ultimo, è un repository, è una raccolta di best practice per lo UI testing che il buon Stefano cura insieme a un altro contributor giusto? Un altro maintainer, il nome non lo ricordo ti prego scusami ed è fighissimo perché in realtà hai coperto quasi tutto, anzi ti dico una cosa io da figlio di buona donna sono andato a cercare se avevi coperto il synthetic monitoring, abbiamo parlato oggi di synthetic monitoring, però è praticamente quel testing continuo che si fa con temporizzato, ogni giorno a mezzanotte io testo tutta la mia UI per vedere se qualcosa si rompe.Ecco ha coperto anche quello e che cazzo! Sai che io dal mio punto di vista invece mi sento un po' colpevole perché la repositoria che utilizzato da tanti e nel tempo anche perché gente mi ha scritto per ringraziarmi, perché ho imparato un sacco eccetera, ma io mi sento un po' colpevole perché non sto riuscendo a dedicare il tempo che dovrei a mantenerla, quindi sono alcuni contenuti che vorrei un po' aggiornare o aggiungere tante altre roba, non ce la sto facendo quindi, sono contento che a tanti piaccia e io comunque mi sento un po' colpevole, ecco.Noi comunque ringraziamo a te e i tuoi compagni di viaggio perché il repositor è molto figo, lo condividiamo nelle notte dell'episodio, ma sta sul github di Stefano Poi.Tutti i link sono sulla descrizione.Eccoci qua, un'ora e mezza, mamma è volata! Sì, come al solito, ma potremmo parlare per altre cinque ore, solo perché abbiamo messo limite solo un'ora e mezza.Esatto, anche perché sono divorzio fondamentalmente a questo giro.Io intanto devo scusarmi pubblicamente con Stefano perché in realtà questa puntata sarebbe dovuta essere registrata qualche settimana fa, ma a mia colpa ho fatto un casino come sempre.No, non succede niente, assolutamente.Quindi mi scuso, però ti ringrazio veramente infinitamente a nome mio e della community.Grazie a voi.Non sono sempre molto lesto con le community, ma se fate qualche discussione e volete tirarmi dentro, almeno posso anche rispondere di persona.Ti puliamo.Grazie mille Stefano.Grazie a voi ragazzi.Grazie a tutti.Buona serata.Ciao ciao.Ciao.Ciao Leo, allora, com'è andata? È andata bene, come sempre, ha fatto tutto l'ospite, io ho preso appunti, insomma è regolare, funzionano sempre così le puntate di Gipper.È andata a quello che portava voglia.Io ogni volta che parliamo con un ospite, veramente mi si aprono tanti di quei filoni che vorrei approfondirli tutti e mi rimetto un apposto ecco mi piace proprio questa idea spesso siamo tentati di cadere nella trappola di denny kruger no? Così si chiamava denny kruger io a questo punto ci mettiamo capito di cosa stai parlando poi il nome preciso non preciso è meno importante poi arriva un ospite e ti rimette apposto e ti dice ok Mauro, guarda che hai ancora un po' da capire, da studiare.Certo è che il testing...in Sardo noi diciamo 100 teste, 100 berretti per dire che ci sono veramente milioni di opinioni, opinioni contrastanti ed è, come diceva Stefano, molto difficile farli.Sì, assolutamente, Poi comunque dipende veramente dalle esperienze personali perché è ovvio che cerco di insegnare ai miei corsi qualcosa di oggettivo, ma in realtà io sto insegnando quello che su cui sono passato io.Più esperienze fai e io ho iniziato a insegnare proprio per imparare di più perché ho detto "aspetta, prima di tutto se io non riesco a insegnare vuol dire che non conosco così bene questa tematica".Seconda cosa, vengo pagato per essere esposto a casi di uso diversi che permettono a me di migliorare la mia conoscenza, quindi ogni corso mi permette di migliorare la mia conoscenza perché ho sempre casi di uso diversi, sempre più casi di uso di cui dire "ok, no, questo l'ho visto, questo l'ho visto, questo ce l'ho pensato, questo l'ho visto, su questo ce l'ho lavorato, su questo ce l'ho lavorato, eccetera eccetera" quindi mi torna tutto.Io non avrei altro da aggiungere.Leo? Noi sono abbastanza pieni di informazioni per il momento, però come al solito ogni tanto qualche ospite torna perché poi ci rimuginiamo e dopo un anno e mezzo facciamo adesso...Hai cambiato della roba? Richiamiamola? Oh, ma volentieri perché poi in genere...La maggior parte delle volte non si fa un follow up perché comunque se voi adesso cominciate magari a fare qualcosa, a parlare di coloro, eccetera, ovviamente fra un anno e mezzo avete fatto molta esperienza a quel punto quello che io vi ho detto oggi, sei in grado di dire "questo funziona, questo no, questo non mi torna, questo perché, questo come lo faresti, tu cosa hai imparato nel frattempo?" quindi più che volentieri un follow up.Come diciamo sempre, Gitbar è un po' come il circolo del dopolavoro postale, una volta che tu ne hai fatto parte, è presente negli anni 80 cosa succedeva? Tu entravi con il tuo papà o il tuo zio nel circolo del dopolavoro postale, siccome c'era la possibilità che la guardia di finanza arrivasse e mettesse in mani i tettuti perché il circolo aveva come scopo vendere l'alcol a dei prezzi ribassati perché si è in tassa, ti facevano la tessera.Oggi puoi dire di essere tesserato Gitbar e quindi tu sei libero di entrare qua su Gitbar quando vuoi, quando hai qualcosa di interessante da condividere con la nostra community senza neanche chiedere il permesso, vieni pure c'è sempre una birra fresca per te.Va bene, allora se mi ricordo, perché ovviamente c'è sempre l'intenzione di farlo ma poi ricordassi di farlo diverso, se mi ricordo condividerò di più anche sulla vostra community.Tranquillo che già ti pingo io.Bravissimo, va benissimo.detto questo noi vi diamo appuntamento alla prossima settimana e niente, alla prossima grazie veramente è stato un piacere ciao ciao ciao ciao belli buona serata siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al geet bar e davanti a una birra tutto ci sembra un po' meno grave [Musica] Grazie a tutti! 3
