Bene e benvenuti su GeekVar.Nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Questa settimana abbiamo un oste più che un ospite con noi.Ormai ho smesso di sentirmi ospite già da un po'.Credo di aver lasciato anche lo spazzolina da denti qua.Assolutamente sì, tra l'altro c'è il famoso ragionamento dell'ospite inteso come ospitante quindi in realtà ospite è bisvalido esatto quindi chi è che ospita qui oggi Siamo a casa il github è casa nostra quindi possiamo tranquillamente andare mettiamo i piedi sul tavolo Esatto e ci stappiamo la birra è ovvio con mattia oggi parliamo di un argomento che lui conosce particolarmente bene è che è molto molto divertente e divisivo c'è spazio per delle grosse contestazioni e quindi lasciamo a nostro gruppo teleno so che hai un paio di bombette quante ne vuoi? quindi prima di iniziare, solita noiosa introduzione Info che ho c'è la gitbar.it e brain repos su twitter e il famoso gruppo telegram è questo che stiamo dicendo? Bene sì che tra l'altro io sono rimasto stupito l'altro giorno perché continua a crescere.Si non è che diciamo a un certo punto vabbè abbiamo raccattato tutti i pazzi che potevano starci in giro e ormai non ce ne sono, noi invece no.Continua stabilmente a crescere.cresciamo e questa cosa ci rende molto felici perché vuol dire che in qualche modo ciò che facciamo vi interessa.Detto questo...L'altro, siccome non c'è Alessio lo dico io, c'è anche se ciò che facciamo vi interessa e vi piace e ci volete bene c'è anche lo strumento delle donazioni se non vado errato.Ricordiamo che io sto registrando con un microfono che è stato gentilmente offerto dai donatori di Gitbar quindi se mi sentite forte e chiaro sappiate che potreste sentirmi più forte e più chiaro con delle altre donazioni.Esatto abbiamo giusto dei Neumann da ordinare.Scherzi.Non c'è limite alla spesa per i macropod.Ma sì, ma sì.Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack 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.Detto questo io direi che possiamo iniziare con l'argomento di oggi e voglio che inizi tu Matti, ti faccio una domanda.Vai.Così sveliamo anche il soggetto del nostro discutere.Perché dobbiamo scrivere i test? Ah, è una domanda bellissima a cui ho una risposta semplice e una risposta per cui ti tengo qui fino a domani mattina.Io non mi impegno.Io devo lavare i piatti.La risposta semplice è che i test bisogna scriverli, è una buona idea scriverli per noi stessi tra sei mesi o di tra due settimane o di tra un anno che dovrà mettere mano al codice che stiamo testando, di cui stiamo scrivendo i test e avere una suite di test automatica che ci dice che quel codice fa quello che deve fare è una rete di sicurezza che permette a noi stessi tra sei mesi di poter modificare quel codice liberamente, avendo la certezza che il codice non si rompe nel frattempo e che quindi l'applicazione in cui stiamo lavorando continua a fare quello per cui siamo stati pagati.Però fondamentalmente questo assunto che l'applicazione non si rompe lo stabiliamo esatto prendendo in considerazione il fatto che i nostri test siano ben fatti e coprano tutti i casi ma i test sono del codice che si può rompere e quindi chi testa i test? questa è un'altra bellissima domanda oggi sei ricco di belle domande, alla quale non c'è risposta, nel senso che i test ovviamente ti permettono di scoprire, o meglio, ti evidenziano l'assenza dei bug che conosci.Ti dicono che il codice fa quello che deve fare rispetto al funzionamento che conosci.Quelli che si chiamano in gergo "unknown unknowns", quindi le cose che non sai di non sapere, quelle non si scappa, non c'è un modo semplice di scoprirle.È vero però che spesso capita, scrivendo i test in contemporanea o prima o dopo rispetto al codice dell'applicazione, capita spesso che scrivere i test ti permetta di chiarirti le idee su quello che effettivamente l'applicazione deve fare.Magari stai scrivendo un test e emerge un corner case che non avevi considerato oppure magari tu stai scrivendo sulla base di una specifica scritta in italiano, comunque non in codice, e tradurre la specifica che ti dice quello che deve fare la tua applicazione in codice, quindi scrivere un test che verifica che l'applicazione faccia quello che deve fare, ti aiuta a formalizzarla e magari ti evidenzia dei gap o delle lacune nella specifica che avevi o neanche nell'idea che avevi di come doveva funzionare l'applicazione.Per cui i test sono uno strumento che ti serve a posteriori, come dicevamo prima per il test estodi tra sei mesi, ma ti serve anche nel mentre perché sono uno strumento di scoperta di casi limite dell'applicazione, per esempio.Per cui sì, c'è il problema degli unknown unknowns ovviamente, ed è un problema se vuoi senza uscita.però diciamo che capita spesso, a me è capitato diverse volte, che scrivere dei test ti aiuti a farne emergere alcuni.Io ricordo un po' di anni fa, forse qualcuno più di un po', un talk fatto da uno sviluppatore di Stackoverflow che disse, e lo ricordo chiaramente, "noi non scriviamo i test perché la nostra user base è il nostro test" il nostro compito è solo quello di iterare rapidissimamente, quindi quando c'è una segnalazione siccome la nostra user base sono developer hanno una sensibilità anche nel capire dove è l'errore spesso e a volte Quindi diceva noi abbiamo la sensibilità di iterare rapidamente per mettere una pezza e risolvere queste situazioni.In questo caso lo human testing è considerato come test oppure è una cosa un po' da dire "sì vabbè ma occhio perché potresti incappare in...non ne ho idea eh?" Beh, allora questo è il primo di molti, e ti ringrazio per l'occasione, ma il primo di molti dipende, che dropperò questa sera.Nel senso che il caso di Stack Overflow probabilmente è un caso limite, nel senso che appunto la user base di Stack Overflow è molto peculiare in questo senso e anche il business di Stack Overflow è molto peculiare, nel senso che Stack Overflow non è una banca, non manda razzi sulla luna e non costruisce macchine per fare le operazioni a cuore aperto.Se per caso c'è un bug su Stack Overflow, l'unica cosa che succede è che non puoi copincollare come si fanno gli hook su React.Oppure non puoi prendere il pezzettino C che ti serve per mandare quel razzo sulla luna, perché io sono sicuro che...- Sì, è vero anche quello.Sì, però c'è un livello di indirezione in mezzo, mettiamola così.Stack Overflow non manda direttamente i razzi sulla luna, ma permette alla gente di mandare i razzi sulla luna.- No, scherzo, volevo fare un po' di goliardia.- Per cui, diciamo che la criticità del business di Stack Overflow gli consente questa cosa.In realtà, proprio a proposito dei razzi sulla luna, tante delle best practices del testing automatico in realtà le ha inventate la NASA.Ah sì? Questo non è sempre...Quando hanno iniziato le varie missioni Apollo, molte delle best practices del testing che usiamo tuttora sono nate o hanno preso piede lì.Per cui c'è un grosso dipende appunto a quanto è critico il tuo business quanto un bug in produzione, detto proprio papale papale, ti costa soldi, ti impatta il business e quant'altro.C'è appunto anche il fattore della user base.La user base di Second Flow è super vocale e fatta di gente che capisce di codice, per cui le segnalazioni sono probabilmente molto diverse da quelle del sito delle poste che i vecchi usano per ritirare la pensione.chiaro, chiarissimo.Io ti dico la verità, ho sempre fatto i test, comunque ho sempre abbracciato il mondo del test.Io no! Aspetta però perché c'è sempre la clausola, no? Con un ma.Cioè ho sempre visto il testing in modo molto pragmatico e quando per esempio avevo la mia azienda e prendevo io le decisioni su cosa andava fatto e come andava fatto, ricordo che avevo un approccio molto pragmatico al testing, nel senso che la parte business critical, io gestivo un booking engine, quindi tutta la parte di calcolo del booking, quella era testata a tutti i livelli, unitario, integrazione, quello andremo a vedere.Tutto il resto aveva degli smoke test in modo molto leggero ma in qualche modo ottimizzato e ripensando a questa cosa, perché i budget erano quelli che erano e devi immaginare una piccola aziendina e so che hai una bold opinione anche su quello.Cosa non ce l'ho.Però in questo ultimo periodo ragionavo su una cosa.Da quando ho iniziato gli strumenti per il monitoraggio dei bug si sono evoluti.Penso proprio a Sentry per dirne uno.ok quindi oggi abbiamo degli strumenti per il monitoraggio dei bug che ci permettono di capire dov'è il problema e spesso anche in quale use case specifico no? anche se il più estremo possibile perché l'utonto della situazione che era un pochino più smart del solito e si è messo a modificare il javascript per fare una chiamata che da UI non era permessa a quel punto oggi ha più senso, ha senso reale fare per applicazioni non critiche gli end to end test e fare quel tipo di testing se puoi farla a posteriori e metterci una pezza in modo rapido se sei organizzato per farlo? Ma allora probabilmente no, è vero, probabilmente lo fai end to end con granosalice, lo fai fino a un punto in cui sei confident di aver bilanciato il costo di scrivere e anche di eseguire i test, perché eseguire dei test end to end su un'applicazione comunque richiede tempo e anche probabilmente dell'infrastruttura per eseguirlo, finché sei soddisfatto.Poi è verissimo quello che dici, che comunque i tool di monitoring dello stato delle applicazioni e tutto il tema dell'observabilità in generale ti permette probabilmente di stanare dei bug molto più in fretta e appunto di stanare quegli unknown unknowns molto più in fretta.Per dire, che ne so, se tu hai un monitoraggio del comportamento degli utenti fatto bene e non hai mai testato cosa succede su Safari iOS quando è mercoledì e le condizioni di umidità sono sopra il 25% e hai un bug che succede solo in quel caso lì.Oggi è molto più semplice scoprire che hai un bug che succede in quel caso lì rispetto a quando io ho iniziato a fare questo lavoro e avevo i capelli.Per cui diciamo che è molto più facile spostare verso l'utente tanto del testing utente.Detto questo, però, io credo che resti comunque valido quello che dice il mio caro amico e amico di Gitbar, Fabio Mora, che ogni volta che trovi un bug e lo vuoi risolvere, perché potresti anche decidere di no, ma la prima cosa da fare è scrivere un test che fallisce e riprodurre quel bug.Perché prima di tutto, una volta che lo hai risolto, appunto, hai quella rete di sicurezza che ti garantisce che se tra sei mesi cambi il codice, non avrai una regressione rispetto a quel bug.E poi scrivere un test che descrive quel bug ti aiuta anche a capirne effettivamente la natura.Verissimo, allora ti faccio un'altra domanda che è un dubbio che mi attanaglia spesso e che in realtà per il quale non mi sono mai dato una regola per cui talvolta faccio in un modo altre volte in un altro, ma scrivere il test prima o dopo il comportamento? Un po' l'hai anticipato no? Qual è il tuo approccio? Ma perché? Prima o dopo, tu mi chiedi? In realtà, secondo me, questa è una cosa assolutamente personale e super variabile, nel senso che io stesso a volte li scrivo prima, a volte li scrivo durante, a volte li scrivo dopo.E non ho una regola, nel senso che dipende tanto da che tipo di codice sto scrivendo, per esempio se sto scrivendo una cosa nuova o se sto estendendo del codice esistente o se sto scrivendo qualcosa che coinvolge del front-end oppure no.Tutti questi fattori mi fanno, o anche come mi sono svegliato la mattina probabilmente, mi fanno pendere dalla parte del TDD estremo piuttosto che dalla parte più pigra di dire "buoh, vabbè, intanto scrivo il codice e poi i test li scriverò poi".Non ho su questo, stranamente, una bold opinion.Diciamo che nel momento in cui quello che vai a mergeare o la pull request che vai a mandare o il codice comunque che rilasci ha dei test di cui sei soddisfatto, che tu li abbia scritti prima o dopo il codice, alla fine non frega abbastanza niente a nessuno.Nel momento in cui tu, sviluppatore, sei convinto che...sto spoilerando uno dei prossimi punti della scaletta, ma che la coverage dei test è appropriata a tutti i livelli della piramide, ho spoilerato un altro punto della nostra scaletta, nel momento in cui tu sei soddisfatto di questo, e chi ti farebbe un tanto quanto, che poi questa cosa sia venuta prima o dopo la scrittura del codice, davvero non credo che cambi niente, cambia a livello di appunto processo di apprendimento tuo e di stesura del codice.Però poi una volta che il codice è emergiato, è un po' come dire che una volta che le cose le mangi si mischiano tutte nello stomaco.Una volta che il codice è emergiato non conta l'ordine in cui l'hai scritto.capisco, io dal punto di vista meramente empirico, quindi della mia esperienza, che sono stato ad osservare un po' come mi comporto, è bello quando provi a lavorare e ti immagini che ci sia qualcuno da fuori che ti osserva perché capisci tante cose di quello che fai e io mi sono reso conto che in realtà non riesco a tenere lo stesso livello di impegno, effort cognitivo sulla parte di scrittura del codice e sulla parte di testing.Anche se scrivere i test e scrivere il codice io ho capito che per me c'è un momento esatto dove mi scazzo può essere scrivere il codice o scrivere i test.C'è un momento dove dico "boh non ho più voglia" e a quel punto la mia concentrazione scende, la qualità di quello che faccio scende.Per cui per me la mia regola, ma funziona con me non è detto che debba funzionare con tutti, è quella di scrivere il test prima.Ma non perché c'è la regola che devi rispettare, devi applicare il tdd alla lettera.No, semplicemente perché se io scrivo bene il codice poi il gioco dell'iterazione di test rosso test verde mi aiuta a fare ad avere quel ritmo, quella sequenza che ti riporta sempre sull'attenzione sulla concentrazione.Rani test stacchi per qualche secondo vedi test rosso, ci rimetti mano, stacchi per un altro secondo ed è più ritmato lo sviluppo rispetto a scrivere il codice e poi attaccarci il test sopra, perché spesso quando si fa il test a posteriore, e parlo sempre della mia esperienza, mi trovo a fare un test per il codice che ho scritto e non per il problema che volevo risolvere.Sì, certo.Però è verissimo il tema del ritmo e della cadenza, secondo me è super importante, nel senso che rispetto al momento in cui scrivere i test, rispetto al codice applicativo, c'è tanto un tema di ritmo e di concentrazione, nel senso che magari, sai, ti capita di scrivere o di aver da scrivere una roba particolarmente complessa e magari ti conviene proprio intellettualmente buttartici dentro e scrivere più che puoi finché non ne hai più e poi staccare un attimo la testa e scrivere i test o viceversa.Però proprio perché passare dal codice applicativo al test richiede un minimo di context switching, anche lì c'è da tenere in considerazione questa cosa.Non è context switching vero, nel senso che stai lavorando sempre sulla stessa feature, però è vero che lo sforzo intellettivo che richiedono le due cose è leggermente diverso.Esatto.Mi stava venendo una cosa, ma non voglio anticiparla per...No spoiler! non spoilerare tutto subito.Un altro utilizzo del test e non ne abbiamo parlato oggi.Io, Matì, ormai la scaletta è andata quindi parliamo...Ma sì, perché abbiamo mai seguito una scaletta in tutta la nostra vita? Assolutamente no.Ma poi tanto gli ascoltatori non la vedono, quindi posso dire anche che nella scaletta c'era Marisa Laurito e loro non lo sapranno mai.Cavolo, hai svelato il tuo special guest! No, ehm...Eh purtroppo c'è un paccati all'ultimo, non è potuta venire.Ma mi rifarò sulla gente, sappilo.Eh...Fare il testing, o comunque occuparsi di scrivere test, può anche essere visto come un'attività di documentazione del codice.è spesso una delle cose che si fanno per capire come si comporta il codice e cosa fa fondamentalmente è buttare un occhio ai test quindi il test di per sé è uno strumento di comunicazione perché comunica, come hai detto prima tu, al tè del futuro ma può comunicare ai tuoi colleghi che dopo un mese devono prendere in mano quella feature e non hanno voglia di leggere cosa fa una funzione di 50 righe forse c'è un problema se è scritto una funzione di 50 righe ma questo è un altro discorso quello lo lasciamo ad Uncle Bob che c'è sempre qualcosa da dire ma in quel caso buttano un ok test e guardano i vari casi e anche solo dal titolo del test si capisce cosa fa e allora dal tuo punto di vista esistono degli accorgimenti per rendere il test più eloquente, più comunicativo, più capibile? Sì, molto.È una domanda interessantissima perché è vero quello che dici, nel senso che anche a me capita quando approccio un pezzo di codice a cui devo lavorare che non conosco, di dire "Va beh, vediamo se ci sono dei test" sperabilmente ci sono e parto da lì per capire qual è l'intenzione che sta dietro questo pezzo di codice.E questo ci dice anche che, come dicevamo prima, lo sforzo intellettivo anche per leggere i test è diverso da quello per leggere il codice.ho letto di recente un post molto bello che diceva che nel codice dei test, per esempio, una regola fondamentale del codice applicativo, che è la regola dry, don't repeat yourself, nel codice dei test non vale.Nel senso che nel codice dei test invece ha molto senso essere espliciti nel descrivere il contesto attorno all'oggetto che stai testando anziché rifattorizzarlo fuori in un'altra funzione.Mettere i test dentro un ciclo 4 che Dio vi maledica.Esatto.Che Dio vi maledica.Per cui tante delle regole che noi diamo per scontate spesso e volentieri e che magari abbiamo così tanto interiorizzato che ci viene spontaneo applicarle quando scriviamo il codice dei test in realtà nel codice dei test non hanno molto senso e anzi lo rendono più difficile da usare per quell'uso di documentazione di cui parli tu.Vero.Anche lì è diverso scrivere il codice.E' sempre codice che viene compilato ed eseguito tanto quanto il codice dell'applicazione ma è un tipo di codice diverso.Assolutamente.Con delle regole stilistiche diverse.Io però su questo, sai, ho una, come sempre, un'opinione confligente, no? Cioè, bisticcio con me stesso fondamentalmente.Perché poco fa, l'ho appena lanciata con tanta rabbia, no? Perché nel penultimo progetto dove sono trovato a lavorare con Go, che voi sapete che io amo, alla fine, è il mio linguaggio di programmazione preferito, ho visto che all'interno della codebase, e non voglio dirla grossa ma pare sia una pratica comune, i vari casi erano definiti su una struttura dati e iterati dentro un foro.Quindi in realtà era perfetto perché rendeva il codice meno verboso possibile.Però allo stesso tempo diventava molto difficile capire, comprendere e vedere a colpo d'occhio le casistiche, i vari case.Quindi mi dico, se io metto il codice del test dentro un FOR, il mio codice dry, non mi sono ripetuto, è facilmente manutenibile.Tanti ti direbbero che è codice bello.Esatto, ma quando vado a leggerlo e se lo uso come strumento di comunicazione, a primo chiatta ci capisci una cipa.nel senso che diventa proprio ci devi mettere carico cognitivo per capirlo.D'altro canto mi scrivo i miei vari casi semplici, semplici, belli, anche un po' verbosi, però dove tutto è comprensibile ma allo stesso tempo diventa complesso da mantenere perché se io modifico il mio codice esatto devo prendere in mano 400 righe di codice per i miei 10 casi o 15 casi e quindi come ne esco? La soluzione è molto semplice, è usare Go e usare dei linguaggi come ad esempio i linguaggi della JVM che hanno dei framework di testing fatti bene come JUnit che è un framework che esiste da una vita e mezza e fa il suo da una vita e mezza e ha delle feature molto belle come il parameterized test che è una cosa che ti permette di definire una sorgente di parametri può essere per esempio un enumeration, una lista di stringhe, un file di testo o una funzione che ritorna a una lista di argomenti che tu passi a una funzione di test e ognuna di queste è un test case per cui entrambi i vantaggi hai il codice dry, nel senso che tu scrivi un solo test a cui passi una serie di coppie input valore atteso composta da tutte le possibili combinazioni di input e valore atteso e ognuna di queste è un test case diverso che può fallire indipendentemente dalle altre quindi quando fallisce uno tu sai esattamente con quale valore è fallito di input.Vabbè anche Go in realtà funzionava così, anche se poi nel cicloforo e dentro c'era il test.Però a quel punto tu cosa fai? Ti basi sui parametri di input quando vai a leggere il test, no? Cioè come approcci a quel tipo di test? Puoi farlo in mille modi diversi, sì.Ovviamente poi ci sono dei test che si prestano meglio di altri a questa cosa, e test per cui non ha senso farlo.però, sì, diciamo che tu hai, che ne so, io l'ho fatto di recente, tu hai, non lo so, una funzione che riceve una stringa in input e ritorna un valore a seconda di come è fatto l'input.E ovviamente dire, non lo so, se passi stringa vuota fai così, se passi una stringa di più di tot carattere fai quest'altra cosa così, è un caso che si presta molto bene.e lì davvero il codice del test stesso era completamente identico e quindi secondo me lì c'è un vantaggio nell'avere il codice del test dry e dire ok, queste sono le coppie input output atteso e il comportamento che io voglio verificare è sempre lo stesso cioè voglio che a questo input corrisponda a quest'output, a quest'altro corrisponde a quest'altro output, e così via.Per cui quando hai delle coppie di input e output ben definite, secondo me in quel caso ha senso.Ci sono dei casi invece in cui essere dry non ha senso, per esempio, adesso vai spoiler un altro punto della scaletta, ma quando stai facendo del test, del testing, usando dei mock di dipendenze esterne e hai, per esempio, il contesto attorno all'oggetto che stai testando di cui definisci il comportamento con dei mock, definirlo una volta sola per tutti i test rischia di diventare poco leggibile perché hai la definizione del contesto lontana dall'esecuzione del metodo che stai testando.se tu pensi, per esempio, alla forma classica di come sono scritti i test nella forma "given, when, then", per cui tu dici che, dato questo contesto, quando il mio componente che sto testando fa questa cosa, allora voglio che succeda questo, queste tre cose dovrebbero essere più vicine possibile.Mentre se tu la parte di "given" la fattorizzi in, per esempio, un'altra funzione esterna, di fatto le stai allontanando e leggere il test diventa un po' più complicato perché hai aggiunto un livello di indirezione in più.Sì, chiaro, assolutamente sì.Io di solito...In sostanza dipende.Che è la parola magica della puntata di oggi.Della vita.Io in realtà tendo a fare i mock sullo stesso file, fondamentalmente lavorando in javascript con geste sullo stesso file del test in modo proprio da avere chiaro il contesto come dici tu vero è che dipende molto dal codice che stai andando a testare dal framework che stai utilizzando dalle librerie che stai utilizzando perché talvolta ci sono delle librerie che meno si prestano a fare i test e quindi ti troviamo a moccare lo scibile giusto per far funzionare una microcosina fino ad arrivare a fare il monkey patching per non far esplodere tutto e ci arriviamo subito.Prima da lì secondo me è un tema molto interessante anche soprattutto quando ti trovi a lavorare con del codice legacy che non era testato ma tu sei una brava persona invece lo vuoi testare è quella cosa che è davvero difficile da misurare che si chiama testability del codice A un certo punto se tu ti trovi a dover moccare 150 cose per passare un valore a una funzione il problema è tuo, è del tool di testing, è del linguaggio o è del codice che stai testando? boh, vai a saperlo, cioè nel senso io una risposta me la do spesso ed è sempre l'ultima - eh, sì, solo che è vero che ci sono dei contesti che sono più difficilmente testabili - eh sì, certo, certo specie se ragioni non a livello unitario ma magari a livello di componente quindi un pochino più grande dove vai a testare più elementi che entrano in gioco posso dirvi no? capita spesse volte di dover moccare il router di react e magari quelli che ha scritto il codice prima di te ha messo della roba nello stato quindi devi moccare anche lo stato insieme al router quindi hai ragioni tu però c'è da dire che da una parte c'è il codice che ti trovi in ineredità o che hai scritto tu che andava a essere scritto meglio d'altro canto hai anche dei contesti dove talvolta sono più difficili da testare e in quel caso il test può passare di livello cioè o perlomeno una delle strategie può essere fare un test a un livello superiore e qua introduciamo un nuovo argomento che è la testing pyramid.Che è questa piramide? Allora è una figura geometrica composta da triangoli.No, è una piramide perché ha una base molto ampia e una punta molto stretta.talvolta.Idealmente, ovviamente.Quindi sostiene che esistano livelli diversi di testing in termini di profondità e ampiezza del codice testato.Per cui alla base della piramide ci stanno gli unit tests che testano i singoli componenti in isolamento, poi a un livello superiore ci sono gli integration tests che testano le interazioni tra i componenti in un contesto un po' più articolato e in cima ci sono i test end-to-end che testano l'applicazione nella sua interezza e in maniera olistica.Poi ci sono anche i test fatti a mano, in cima ancora, che idealmente dovrebbero essere ancora meno.È una piramide appunto, perché l'idea è che se tu hai un'applicazione articolata, fatta da tanti componenti, gli unit tests sono tanti, tanti quanti componenti che compongono la tua applicazione, i test che testano le interazioni tra componenti invece sono sotto insieme perché testano aggregati di componenti, e i test che testano feature intere della tua applicazione sono ancora di meno, perché testano appunto uno scope molto più ampio.Per cui sì, quello che dici tu ha molto senso quando è difficile testare un componente in isolamento potresti testare come si comporta rispetto ad altri componenti o come si comporta in un contesto più articolato eh, assolutamente potresti anche dire, ed è quello che dice DHH ed è una delle tante cose che dice DHH a cui non sono d'accordo che fare unit testing non ha senso perché è una perita di tempo e lui testa tutto end to end o al massimo fa gli integration test volevo arrivare là perché in realtà ho fatto attorno alla puntata 20 ho fatto una puntata sul testing dove l'ho sparata ok però sì adesso vi dico cosa ho detto poi se volete più dettagli vi andate a riprendere la puntata parlo di cypress e poi magari prima della fine della puntata vi do il numero preciso in questo momento non ce lo so a tua mano però fondamentalmente la testing pyramid quella teorizzata da mike cohen si dice così spero vabbè ma tanto ormai lo sapete che io storpio praticamente tutto.Se dovessero ascoltarci mike cohen noi ci scusiamo per l'eventuale pronuncia sbagliata della sua.Assolutamente sì e può venire qua in onda per correggerci.No, fondamentalmente l'hai detto prima tu, quindi tanti piccoli test unitari che testano i nostri pezzettini di codice in isolamento, test di integrazione che testano i pezzettini che comunicano tra di loro, quindi con dei contesti un po' più ampi e test end to end che testano dall'inizio alla fine in profondità la nostra applicazione come se fosse una verifica definitiva a completa validazione di quello che abbiamo fatto.E la butto là.Quando feci quella puntata io proposi un altro approccio che ho provato e devo dire che ha funzionato in quel momento specifico, in quello specifico contesto.di un'azienda piccola con tipo me e un'altra persona o altri due persone a sviluppare che devono deliverare tanto prodotto in fretta e talvolta anche di qualità pessima e qual era la proposta in realtà? Quindi immaginate un approccio startup paro alla situazione.La proposta era io mi faccio gli end to end test in modo da coprire i casi più importanti e più casi possibile dell'applicazione.È vero che gli end-to-end test hanno un costo perché sono lenti in esecuzione anzi lentissimi ma tanto non li eseguo io, li eseguo la CI.Se ci mette un'ora in più a farmi il testing vabbè chi se ne frega pago un'ora in più di virtual machine è tutto a posto.Utilizzo un altro strumento che andremo a vedere dopo che invece è il code coverage per vedere i pezzi di codice non testati end to end dalla mia suite di test e quei pezzi me li vado a coprire con test di integrazione e unitari in quel modo io riesco grosso modo ad avere una coverage ampia ma allo stesso tempo concentrarmi sulle feature e sugli use case specifici a livello generale e non unitario.Ti sembra così assurdo questo approccio? Per niente mi sembra estremamente pragmatico e tra l'altro è è una cosa assolutamente sensata, soprattutto in un contesto, appunto, diciamo, non over-ingegnerizzato, per dirla in maniera costruttiva.Perché, per esempio, invece, altri contesti, io so, dalla mia esperienza passata in Google, che ci sono progetti in cui, se tu vuoi essere certificato come progetto decente, che magari della gente ci contribuisca e vuoi anche solo rilasciarlo in produzione se hai la code coverage sotto il 95% a non presentarti nemmeno.Per cui diciamo che anche lì il solito dipende.Se sei in un contesto in cui appunto rilasciare tanto, forte e velocemente è molto più di valore che magari avere della manutenibilità, della testability, del codice bello e quello che vuoi, questa roba mi sembra assolutamente valida.Credo che farei la stessa cosa.Non ti nascondo che nel progetto di oggi invece l'approccio è diverso e per quello che dicevo molto dipende dal contesto, l'approccio con cui vai a testarlo.Io mi rendo conto di una cosa adesso scrivere del test di qualità è come scrivere del codice di qualità.Talvolta si ha bisogno però di codice che funziona e non di codice figo che funziona.Quindi ti turi il naso e per bene del prodotto per bene del business devi deliverare.Dobbiamo dobbiamo essere pragmatici.Poi certo se lavori in Google e hai il tempo per dedicarti a scrivere bene il codice magari rifattorizzi quella IF 70 volte finché non hai il cosino.ma va bene è quello che faccio oggi nel progetto dove sono ma allora non c'era il budget per fare codice sai torno torno di nuovo alla mia primissima affermazione di oggi per cui tu i test li scrivi per il test stesso di tra sei mesi però se al test stesso di tra sei mesi interessa avere i bonifici in fretta più che avere la test coverage tra sei mesi quando dovrai mantenere questo progetto è una cosa assolutamente legittima Il tessesso di oggi può dire "Io sono perfettamente convinto che questo codice funzioni, mi servono i soldi che questo codice mi darà e i test li scriverò nel 2000 mai".anche perché quando fai l'ex-sigla...Ovviamente se poi invece tra sei mesi il testesso di tra sei mesi bestemmia addosso al testesso di oggi perché deve mantenere quel codice e tu oggi non hai scritto i test e ti sei assunto questo, se vuoi questo rischio hai assunto quello che di fatto poi a un certo punto è un debito tecnico Assolutamente tecnico perché l'assenza di test è un debito tecnico e tu stesso mi hai insegnato che il debito per un'azienda in crescita è uno strumento per cui tu puoi scientemente decidere di contrarre un debito non scrivendo dei test perché in questo momento ti interessa di più qualcos'altro ma è perfettamente legittimo farlo Sai cosa cosa penso penso che spesso per quanto riguarda l'argomento del testing ma ci sono altri argomenti così caldi nel nostro mondo.L'approccio dogmatico è quello sbagliato dal mio punto di vista.Lo vieni a dire a me che ho già detto diverse volte "dipende".Sì sì ma è proprio per rinforzare quello che dicevi tu.Nel senso che spesso quest'approccio da dottrina si dimentica del contesto e questo succede quando vai a progettare architetture, Ti faccio un esempio io mi sono trovata ad aver progettato un'architettura fighissima super articolata code cose mazzi Da una parte mongo dall'altra postgre dovevi sincronizzare fare mi tutto bellissimo no scintillante Poi due persone che devono mantenere tutto quello ok iniziamo a tagliare questo database va via buttiamo tutto dentro a posgre, questa coda, c'è un modo più snello per farlo? ok prendiamo questo servizio, eliminiamo...capisci? alla fine devi anche fare economia da quel punto di vista e talvolta economizzi dove non dovresti a discapito di magari delle spese eccessive invece quell'approccio un po' ibrido di testing mi sembrava un buon trade off per avere una coverage decente nel senso che almeno gli use case dell'applicazione erano coperti e poi tutto funzionava.Tempo fa, giusto per andare avanti, se no...- Mi aggiungo giusto una roba nel senso che come sai e come probabilmente sanno anche gli ascoltatori di Gitbar io sono una delle persone persone più antidogmatiche del mondo.E io stesso, anzi, rifuggo così tanto all'approccio dogmatico che per lunghi anni della mia carriera da sviluppatore mi dicevo "ah, i test sono una perdita di tempo, il codice lo eseguo, vedo che funziona, e va, fa quello che deve fare, mi pagano, e sto a posto così e non ho intenzione di contrarre questo debito tecnico".In questo caso, però, ti confesso che sono abbastanza un convertito, nel senso che poi ho scoperto invece che i test hanno un valore gigante ed è quello di cui stiamo parlando oggi e come tutti i convertiti sono un filino dogmatico.Mi rendo conto che sull'importanza dei test sono un filino dogmatico.come il classico caso di quelli che smettono di fumare e diventano gli antifumatori più accaniti del mondo.In quanto convertito al verbo del testing, io adesso, per dirti, sono quello che nel team in cui mi trovo adesso ha introdotto i test e quello che rompe il cazzo alle pull request se non hanno una test coverage adeguata.proprio perché ci ho sbattuto la faccia in prima persona e sono stato quello che...sono stato il me stesso di tra sei mesi che si bestemmia addosso perché non aveva scritto i test.Per cui capisco perfettamente l'approccio pragmatico e lo condivido.Non è che ti dico mai nella vita scrivere del codice senza i test.Io stesso ho scritto del codice senza test e lo scrivo tuttora, spesso e volentieri.però è una decisione che se non altro verso la quale sento un po' di attrito.Amico mio io ti capisco appieno, tu quando mi guardi devi vedere una persona che bisticcia con sé tutti i giorni ma per dirtene una, ultimo progetto, parlando col team io sono colui che ha rotto il cazzo per testare gli svg io ti apprezzo molto e ti rispetto infinitamente capisci che livelli per fare almeno uno snapshot test sugli svg perché gli svg fatti come componente react possono prendere dei parametri e quindi almeno snapshot e se vedi che qualcosa fai la...ti rendi conto che stai distruggendo qualcosa.Perché? Perché fondamentalmente in quel caso aveva senso.Nel senso che aveva talmente senso che per esempio mi son battuto per fare anche un altro tipo di testing poco utilizzato che è il visual regression test, che è una figata pazzesca, specialmente nella UI e costa un botto della madonna c'è un tool fighissimo che vi porterò come balocco, ve lo spoilerò, però che se il pulsante si muove di un pixel ancora prima dello UI UX che ti telefona c'è il tool che ti manda la notifica perché tanto se hai uno UI UX nel team, sappi che ti manda il messaggio su Slack.Se fai un bottone con gli angoli arrotondati di un grado in meno lui lo sa.Esatto, esatto.Abbiamo parlato di TestingPyramid e io so che tu spesse volte ci parli delle scuole, no? - È il mio flame preferito in assoluto.- Di Londra e della scuola di civiltà.- È uno dei miei flame preferiti in assoluto.Nel senso che non è un mistero, lo sanno un po' cani e porci, soprattutto gli ascoltatori del gruppo Telegrami, sono il maintainer, non in maniera del tutto intenzionale, di un framework di mocking, che si chiama Mock.K ed è il framework di mocking di riferimento di Kotlin.Quando parlo di mocking con le persone, spesso e volentieri mi scontro con i dogmatici della scuola di testing di Chicago o di Detroit, che dir si voglia, che è la scuola di testing di Kent Beck, per non fare nomi.Per cui è quella scuola che ti dice che tu i tuoi componenti li devi testare come se fossero delle scatole nere.devi testare il loro comportamento in maniera completamente indipendente da quello che ci succede dentro e quello che ti dice la Chicago School è che tu devi anche costruire le tue applicazioni in quest'ottica, quindi quando si fa il paragone tra le due scuole di pensiero si dice che le applicazioni le costruisci inside out, quindi costruisci prima i componenti e poi li metti assieme.Per esempio, tu sai che hai un'applicazione, che ne so, che fa, riceve delle richieste HTTP, salva dei dati su database e ti ritorna degli altri dati.Tu costruisci lo strato di persistenza indipendentemente da tutto e lo testi.Costruisci lo strato di controller HTTP, lo testi indipendentemente.Costruisci la logica di business, la testi indipendentemente e poi a un certo punto metterai tutto assieme e probabilmente, si spera, ci farai degli integration test e dei test end to end.Ma i test e i componenti vengono progettati in maniera completamente indipendente l'uno dall'altro e testati in maniera indipendente l'uno dall'altro e testati come delle scatole nere, senza sapere cosa succede all'interno.Ok, ci può stare, è una scuola di pensiero.Un'altra scuola di pensiero, che è appunto quella di Londra, sempre per non fare nomi di Freeman e Price, che hanno scritto un libro meravigliosissimo, che metterò nei balocchi, dice che tu le applicazioni le puoi disegnare anche al contrario, le puoi disegnare outside in e disegnare quindi prima la feature intera, dire "ok, io ho un coso che riceve una richiesta HTTP, salva dei dati su database e ti ritorna un oggetto".E...ok, quindi adesso io inizio disegnando il primo endpoint della mia applicazione, che è lo strato di connessioni HTTP.Questa roba dovrà interagire con uno strato di persistenza, ma quando io voglio testare il mio strato HTTP in relazione allo strato di persistenza, io questo strato non ce l'ho a disposizione, perché non l'ho ancora scritto.Allora, per testare il comportamento del mio strato HTTP rispetto allo strato di persistenza, cosa faccio? Mi costruisco un mock, che è un oggetto che si comporta come, allo stesso modo, del mio strato di persistenza e nel mio test io posso anche descriverne il comportamento, ma non è quello vero.Questa cosa è un'affermazione potentissima, nel senso che avere degli oggetti che si comportano come il contesto intorno al componente che stai testando, ma non sono quelli veri, è uno strumento potentissimo, per esempio, se tu sei in un ambiente di CI e non hai un database sotto mano, perché non hai voglia di avere tutto lo strato di connessione a database disponibile per il tuo ambiente di CI.Quindi potresti dire, ok, il mio strato di connessione HTTP fa queste richieste, è una cosa che funziona molto bene in un contesto obiett-oriented, ovviamente.Se tu immagini i tuoi componenti come degli oggetti che si scambiano messaggi, quindi di fatto si invocano delle funzioni a vicenda e si ritornano dei risultati, tu dici, io voglio che il mio strato di connessione HTTP mandi questi messaggi, chiami queste funzioni dello strato di persistenza.E voglio anche, per esempio, poter guidare il comportamento del mock del mio strato di persistenza all'interno del test.Quindi voglio poter dire quando io chiamo il metodo save del mio strato di persistenza, che io in questo momento non l'ho ancora implementato, quindi internamente non so cosa faccia, ma voglio poter dire quando chiamo il metodo save mi ritorna l'oggetto salvato e quindi so che voglio che abbia l'oggetto ritornato l'id non nullo.Per esempio io gli passo un oggetto con l'id nullo, il mio strato di persistenza lo salva e popolerà l'id in base a come è stato ritornato dal database e ritorna indietro un oggetto che ha l'id non nullo.Questa cosa io la posso fare tramite un framework di mocking che posso essermi iscritto da solo, posso usare il mio, posso usare quello che c'è in qualunque linguaggio perché qualunque linguaggio in realtà che si degni di questo nome ha un framework di mocking, persino PHP ha fake, che è un framework di mocking discretissimo che fa il suo.E quindi io posso non solo guidare il comportamento del contesto intorno all'oggetto che sto testando, delle dipendenze dell'oggetto che sto testando, posso dire e verificare come si comporta il mio oggetto in corrispondenza di alcuni comportamenti che avvengono al suo intorno.Ma posso anche verificare che il mio oggetto mandi all'esterno, alle sue dipendenze, i messaggi che mi aspetto che mandi.Per esempio, voglio dire se mi arriva una richiesta HTTP che non è valida, io voglio che su database non venga salvato niente.Quindi posso dire che in corrispondenza di un input al mio strato di connessione HTTP voglio essere sicuro, voglio testare, che non venga mai chiamato il metodo save del mio strato di persistenza.E in questo momento ancora il mio strato di persistenza non esiste.È un mock, è un oggetto che so che esisterà, che farà delle cose...[Alessio] Una controfigura.è assolutamente una controfigura, uno stunt double, tant'è che infatti il termine generico per identificare Mok è proprio "test double" è esattamente come una controfigura e tu sai benissimo che adesso volevo arrivare là, quando si parla di testing di Mok si entra in un mondo di terminologie che ricordo ancora quando ci approcciai la prima volta un po' di anni fa ormai si vede nei miei capelli bianchi almeno tu li hai sì ma stanno andando via molto rapidamente un po' mi trovai disorientato no? perché si parlava di mock, si parlava di stab, si parlava di dummy object, si parlava di spie esatto proviamo a mettere un po' d'ordine È veramente un casino nel senso che ci sono framework che li mischiano per cui quello che si chiama mock in un framework è uno stab per un altro framework e quello che si chiama fake per un framework è una spia di un altro, è un po' un casino.In generale, ed è la mia opinione, è come la vivo io, probabilmente il maintainer di altri framework i marking la vedono in un modo diverso.Però io chiamo spie, è la cosa più facile, è un oggetto vero che quando tu gli chiami un metodo lo esegui veramente, ma oltre a fare questa cosa registra le chiamate ai metodi.Per cui tu alla fine puoi fare delle asserzioni sul fatto che queste chiamate sono avvenute e con quali parametri.Per cui ti permette di dire, appunto, quello che dicevamo prima, verifica che sia stata chiamata la save del mio strato di persistenza oppure no e con quali parametri.All'interno del test tu puoi fare questo tipo di asserzioni.E fa solo quello.Stab è l'oggetto duale, nel senso che non ti permette di fare delle asserzioni, non registra le chiamate, ma ti permette di guidarle.Quindi puoi dire "quando chiamo il metodo save mi ritorni", se io chiamo il metodo save con questi valori mi ritorni in alla, per esempio.E quindi tu puoi, tornando alla scrittura di test di cui parlavamo prima, given, when, then, a me piace molto identificarli così.Spy sono quelli che tu usi nella parte then, sono quelli su cui tu fai le asserzioni per verificare che sia effettivamente successo quello che l'oggetto ha registrato.Stub sono quelli che usi nella parte given, sono quelli che usi per definire il contesto attorno al tuo oggetto di cui vuoi verificare il comportamento.Nella mia concezione, che non so assolutamente se sia giusta, i mock sono delle cose che ti permettono di fare entrambe le cose, nel senso che tu puoi stabbare il comportamento, ma puoi anche spiarne il comportamento perché registrano le chiamate.E che altri termini ci sono? - Vabbè, i dummy object.- I dummy object.In realtà è una cosa molto interessante, perché da maintainer di un framework di mocking, una buona quantità di issue che vengono aperte sono ok, sono...ho provato a mockare questa classe e non funziona.In realtà, la cosa interessante, e su questa cosa Tim Vanderlip, che è il maintainer di Mockito, ha scritto un post molto bello, che dice che non bisogna mockare mai i value object.È una pessima idea mockare i value object.Prima di tutto perché in tanti linguaggi, soprattutto quelli JVM based, sono implementati in maniera diversa dalle altre classi.In Kotlin soprattutto ci sono le classi in line, dalla 1.6, che sono veramente stronze.Mockail le supporta, ma è una roba davvero, davvero, davvero arcana, che nemmeno io so come funzioni.E soprattutto i value object sono oggetti che contengono solo un valore, non hanno un comportamento.per cui mockarli è una forma di over-ingegnerizzazione stupida, nel senso che non ti serve un mock.Se tu hai un oggetto che contiene il valore 5, non ti serve mockare, che quando prendi il valore ti ritorna 5.Costruisci un oggetto con dentro 5 e, per dirla in francese, non mi romperai i coglioni.[Risate] Per cui c'è questo tema, c'è un tema molto interessante di, e probabilmente un po' l'abbiamo toccato e un po' lo toccheremo ancora, cosa ha senso testare, ma c'è un tema molto grosso di cosa ha senso mockare, nel senso che se è una cosa di cui vuoi guidare il comportamento, su cui chiami dei metodi e su cui vuoi verificare che questi metodi non sono chiamati, ok, mockala.Se è un value object ti stai sparando nei piedi se lo vuoi mockare.Sì, chiaro, chiaro.Io ho una domanda che mi viene un po' dal contesto e dall'ambiente nel quale lavoro.Io lavoro per molto del mio tempo in TypeScript, JavaScript e quel mondo là, no? E talvolta alcune cose non sono scritte proprio benissimo, quindi per moccarle...- Per il proprio uso degli eufemismi.Sì, esatto.Fai una cosa che io chiamo il "monkey patching".Ok, quindi "monkey" facendo "monkey patching".Come lo vedi, come approfusci? Non dirmi malissimo, però...No, vabbè, ci sono dei linguaggi che lo permettono e dei linguaggi in cui anzi è assolutamente idiomatico.JavaScript stesso in realtà è un linguaggio che lo permette e lo incoraggia in qualche modo.Alla fine della storia, sai, il mocking stesso in un contesto obiettoriente ed estrettamente tipizzato come quello della JVM non fa nient'altro che quello, nel senso che ha un framework di mocking e in realtà quello che fa è costruirti una sottoclasse della classe che stai mockando con delle feature in più, che sono la registrazione delle chiamate, la possibilità di definire il comportamento dei metodi.Però non è né più né meno che monkey patching.In Java è più difficile.Però, per dirti, io mi ricordo di aver guardato dentro un framework di mocking molto carino che usavo da giovane quando scrivevo JavaScript, che si chiama synon.js e non fa altro che quello.Cioè, fa internamente del monkey patching degli oggetti.ti espone poi un'interfaccia un po' carina ed è fondamentalmente Syntactic Sugar.Però ti faccio l'esempio.Però quello fa.Ti faccio l'esempio.Una buona pratica per fare tutto ben testabile è quello di usare la Dependency Ignition.Quindi ti inietti le indipendenze in modo che sono facilmente testabili perché al posto di passare una certa dipendenza ci passi il tuo mock o la tua spia o quello che ti serve in quel momento e tutto funziona a modino.Talvolta la dependency injection è un'opinione nel senso che non la trovi dappertutto e quindi quando ti parlavo di monkey patching spesso e spesso lo faccio mi trovo a importare delle librerie e moccare quelle librerie patchandole in modo che tutto funzioni.E mi rendo conto che talvolta è un approccio un po' vichingo.Un po' sì, però è anche un approccio pragmatico, nel senso l'approccio ingegneristico ti direbbe riscrivi quella roba con la dependency injection e inghietta delle dipendenze muccate, però ce n'hai voglia? Ne vale la pena? Ma anche no.Soprattutto se il linguaggio che hai ti consente di fare il mochie patching a un costo molto contenuto come fa javascript.Esatto, esatto.Beh, io devo ammettere.Tra l'altro mi sono perso, poi mi sono infervorato perché come dicevo prima il flame tra l'Home School e Chicago School è il mio preferito di tutti.tutti, però appunto quando parlo di mocking tutti mi dicono "ma no, ma che schifo, devi testare blackbox, ci sono dei casi in cui non puoi farlo".Aspetta però, torniamo per un attimo alla Chicago School.Ok, se ho capito bene, quello che dicevi è realizziamo i componenti in isolamento, ci testiamo il componente e al massimo, una volta che abbiamo tutti i componenti, ci testiamo l'integrazione.Quindi fondamentalmente per la Chicago School non servono i mock.Sono uno stupro i mock per la Chicago School.Ogni volta che parli con un integralista della Chicago School che ha letto TDD Kent Beck ed è il suo libro preferito di sempre ti dice che i framework di mocking sono uno stupro.Il problema è che poi quando vanno a scrivere il codice veramente riescono a scrivere come dicono loro? questo io non lo saccio.Più che altro, no, vabbè, diciamo che in termini molto teorici poi appunto, quando hai a che fare con il mondo reale, il problema è quello, nel senso che cosa fai, ti tiri su un Postgres nell'ambiente di CI, usi test...in ambiente Java puoi usare test containers, che è molto bello, è uno strumento stupendo, per cui con tre righe di codice ti tira su un container docker con Postgres per dire...tu istanzi un oggetto Postgres container nel codice del tuo test e lui internamente fa dei magheggi con docker, tira su un container docker su cui tu puoi fare delle cose.Una roba tipo le github action dove ti dici mi serve questa roba e lui te la espone.Più o meno sì.È molto bello, puoi fare così però a un certo punto gli oggetti tra loro...C'hai anche servizi esterni.Sì, esatto, cioè devi fare una richiesta all'API di Facebook.Come la testi? È vero anche quello che ti dicono gli integralisti, è tu devi fare una richiesta a un'API esterna e la mocki.Quando quell'API di esterna che non dipende da te cambia, tu non te ne accorgi perché non hai cambiato il mock e il tuo test continua a funzionare ma l'API esterna è cambiata.Lo so.Però allora cosa faccio? Non la testo? Appunto, lì io sono, diciamo che a me piace molto la London School perché, per ragioni storiche mie, perché fa parte del mio percorso personale, ha i suoi limiti, nel senso che un limite grosso è che tendi ad avere i test e il codice applicativo molto accoppiati.Cambi una riga di un...del codice applicativo, devi cambiare tantissimo anche i test.Per esempio, l'esempio di prima, no? Anziché fare save di un oggetto su database, fai l'upset.Quindi tu puoi ricevere un oggetto con l'ID e in quel caso devi fare l'update.Quindi cambi il metodo dello strato di persistenza che devi chiamare, devi cambiare tutti i test.Eh sì.Inevitabilmente.mentre se tu lo testassi come una black box andando a fare la query su database che ti dice che quell'oggetto è stato salvato, potresti non interessarti di quello che succede in quel caso.Sono due modi diversi di intendere il testing.Nessuno dei due è giusto o sbagliato.Dipende molto dalla persona e da quello che stai testando.La letteratura ti dice che il problema fondamentale della London School è questo, che ha il test, il codice molto accoppiati.Il problema fondamentale della Chicago School, oltre appunto a quello che dicevamo che non è applicabile in determinati casi, è che rischi, e c'è un rischio concreto, che tu scrivendo ogni componente in isolamento rischi di over-ingegnerizzarlo e scrivere delle cose che in realtà non usi.perché se tu parti dallo strato di persistenza e dici "ok mi servono l'insert, l'update e la delete" ma magari la delete alla tua applicazione non serve non lo sapevi perché sei partito da quel componente lì e hai buttato nel cesso del tempo - Quanto è vero quello che hai appena detto ed era uno dei motivi per cui io partivo sempre dall'end to end nell'approccio startuparo perché partivo proprio dalla feature partivi dall'esterno si ed è un approccio che ho trovato molto interessante e soprattutto proficuo mi sono reso conto che tutte le volte che si parte dall'interno, o almeno io parto dall'interno, mi perdo nel progetto nel senso che o vengo e ingegnerizzo mi ritrovo a fare dei pezzettini del puzzle super fighi ma che poi metterli tutti insieme diventa uno sforzo titanico perché sono veramente complessi li fai articolati in realtà adesso tiro fuori lo studente classico che è in me però Bertrand Russell ti dice che l'induzione, il ragionamento induttivo è un mito esiste veramente, perché quando tu parti, appunto, dall'interno per andare all'esterno, tu in realtà la concezione dell'esterno ce l'hai già in mente, è solo che non te lo stai dicendo esplicitamente.Per cui è quello che ci dicevamo prima, se vuoi che ci sono dei casi in cui il ragionamento inside out non è applicabile, perché tu in realtà un pochino come funziona l'applicazione ce l'hai sempre in mente, è escluso.O stai lavorando in un team che lavora a silos e qualcuno ti ha detto "fai solo lo strato di persistenza senza sapere perché e allora devi cambiare lavoro" Oppure come deve funzionare l'applicazione non puoi non saperlo.E allora ti faccio una domanda, guarda, ma l'hai proprio provocata perché anche su questa io non mi so dare una risposta.Esiste un differente approccio di test al testing se si va a realizzare un'applicazione o se si va a realizzare una libreria, un utility, un tool? Cioè, si approccia in modo diverso, si può approcciare in modo diverso, ha senso approcciare in modo diverso, o fondamentalmente l'approccio è lo stesso.Voglio collegarmi a quello che mi hai appena detto, no? Dello strato di persistenza.Beh, credo che sia di nuovo quello che ci dicevamo all'inizio rispetto a Stack Overflow.Dipende tanto dal caso d'uso che il codice che stai scrivendo copre e dall'utente che hai in mente.Nel senso che, per esempio, io ho lavorato a prodotti per utenti finali, ho fatto siti web di annunci, e lì la user base era estremamente diversa dalla user base che usa il mio framework di Mocking.E anche il caso d'uso era estremamente diverso, Per cui diciamo che gli unit tests che scrivevo allora, quando lavoravo a Kijiji, erano molto diversi, erano degli unit tests che scrivevo per il resto del mio team, molto più che per gli utenti dell'applicazione.MockAI ha dei test che invece sono assolutamente per gli utenti dell'applicazione perché ti fanno vedere come si usa il framework.E quindi fanno parte della documentazione utente, se vuoi.chiaro? chiarissimo io direi che...Kijiji la documentazione utente non ce l'aveva beh gli ha aperto un momento storia bellissimo Kijiji che ha chiuso da poco tra l'altro si ho letto ho il meeting quindi salutiamo Kijiji che ci guarda da lassù io credo che un'idea generale sul testing ce l'abbiamo data data, anzi ce l'hai data.Se poi ci sono appassionati della Chicago School che vogliono venire a litigare sul gruppo Telegram io sono sempre pronto.Può essere un motivo per...D'altro credo, adesso che mi hai detto questa cosa mi hai sbloccato un ricordo, credo, non ne sono sicurissimo, ma mi ricordo chiaramente di aver litigato su questa cosa nel Discord di un Code Motion di qualche tempo fa e sono ragionevolmente convinto di aver litigato con Antonio, con Andrea scusami, su questa cosa.Mi ricordo di aver litigato con uno e poi ho visto questo "jellybelly dev" e io con questo ci ho già parlato ma mi ricordo di averci litigato invece poi è una brava persona quindi comunque sappiate che se ci sono persone che hanno dogmi diversi dai vostri possono essere delle brave persone.Andre è una bravissima persona anche se non gli piacciono i moc.Premesso che ho molti amici a cui non piacciono i walk Posso confermare che Andrea è una bravissima persona Ci manca Andrea! Un'idea generale ce la siamo data A me piace vedere il testing come una missione E l'ho già detto in quel famoso episodio che non ho avuto tempo di recuperarvi ma lo farò prestissimo mentre Mattia ci parlerà del suo balocco fare testing vuol dire ammettere di essere infallibili, di non essere infallibili perché tenere a mente tutte le possibili declinazioni di linguaggio e programmazione che stai utilizzando tenere a mente il dominio tenere a mente la logica applicativa e conoscere il codice scritto da altri che stai utilizzando non è un'operazione umana fatta contemporaneamente cioè il carico cognitivo è fuori da qualunque tipo di controllo quindi è proprio necessario adottarsi degli strumenti e il test ti dà la possibilità se te lo fai bene e se ci impegni effort di in qualche modo aiutarti in questo percorso e fa anche un'altra cosa interessantissima e molto importante.Spesso noi proponiamo il test come lo strumento per ridurre le regressioni e cercare quindi di non distruggere quello che hai fatto.Ma il test può anche essere visto come lo strumento che ti evita di costruire sopra gli errori perché le nostre applicazioni sono in continua evoluzione per cui se noi abbiamo una suite di test che ci aiuta a ci accende dei campanelli d'allarme probabilmente la nuova feature se dobbiamo farla on top o qualcosa che c'è che non funziona bene ripariamo prima quello che c'è che funziona male per costruirla sopra e e quindi non costruiamo o comunque siamo portati a non farlo, a costruire sulle sabbie mobili.Però adesso scoperchi un vaso di Pandora per cui probabilmente faremo un'altra puntata, perché se no stiamo qui davvero fino a domenica mattina, i test non ci assolvono da tutti gli errori, nel senso che a me è capitato spessissimo di dire "ah beh, questa roba funziona, passano e poi no.I test passavano ma c'erano comunque dei bug.Per cui c'è un rischio nello scrivere i test che è quello di avere, o comunque nell'avere i test in un'applicazione, che è quello di avere una falsa sicurezza.Di dire appunto "i test passano, allora funziona tutto" non è vero, perché appunto può succedere che no, perché ci sono ci sono quegli unknown unknowns di cui parlavamo prima e per cui appunto è molto bello quello che dici rispetto al fatto che avere dei test ci permette di asserire la nostra fallibilità e in realtà appunto ci permette di concentrarci sulla fallibilità che ancora non conosciamo.Esatto, quindi ottimizzare gli sforzi.Però appunto non è che asserire la nostra fallibilità ci renda infallibili.Assolutamente vero.Non è una bacchetta magica ma l'abbiamo pensato in tutto l'episodio che diciamo che i test non sono una bacchetta magica.E uso il verbo asserire in contesto di testing non a caso.ovviamente.C'è anche una libreria per gli assert no? Ce ne svariate.Esatto.È stato un argomento interessantissimo e siamo al momento del paese dei balocchi, il momento in cui i nostri ospiti, in questo caso inteso come padroni di casa, ci portano una cosa che li ha catturato l'attenzione, un articolo, video, qualunque cosa sia importante condividere con la community."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi!" Allora, io l'ho già menzionato brevemente prima, in realtà il mio balocco è duplice, nel senso che appunto all'interno del mio flame preferito su questo argomento ci sono due scuole di pensiero che nascono da due testi fondamentali.Uno, probabilmente lo conoscete, se non lo conoscete, conoscetelo, è "TDD by Example" di Kent Beck, che è uno di quelli che, appunto, quando leggi su Hacker News il post "Ask Hacker News", quali sono i libri che hanno cambiato il vostro modo di programmare e che vi hanno resi dei programmatori bravi? ci sono...c'è "Refactoring" di Martin Fowler, ci sono "Itana" in Baum, forse c'è il manuale di C.D.Carnegie-Pike, e poi c'è sempre "T.D.D.by Example" di Kent Beck, perché è effettivamente un classico della letteratura sulla scrittura di codice.È bello.A me, che sono di quell'altra parrocchia, piace da impazzire molto di più il libro di Steve Freeman e Nat Price che si chiama "Growing Object-Oriented Software Guided by Tests" e il titolo è un po' spoiler all'idea di base del contenuto, nel senso che l'idea è appunto che tu parti da un'applicazione che non fa niente, scrivi una feature vuota e poi la fai crescere usando i test come strumento per farla crescere organicamente e costruire tutti i suoi componenti a partire da un'applicazione vuota.Loro usano proprio la metafora di una pianta che cresce perché all'inizio non fa niente e poi un po' per volta, aggiungendo dei test che mockano le dipendenze e poi le dipendenze vere, questa applicazione cresce organicamente e diventa un'applicazione fatta e finita.È il libro che ha introdotto per la prima volta il concetto di mocking, Quindi letto adesso, non so di preciso di che anno sia, non è recentissimissimo, che vuol dire che potrebbe essere degli anni '90, per dire.Però non è nel 1700, ecco.Però letto adesso, soprattutto gli esempi di codice che sono scritti in un Java un po' vecchio, sembrano un filo prolissi.Dici "boh, sta roba...devi un attimo farci la tara, ecco".Io che leggo e scrivo Java da tanto riesco a capire che cosa vogliono dire e a strarre un po' dalla verbosità del Java vecchio stile.Potrebbe esserci un po' di attrito per un giovane che ha sempre visto solo il JavaScript.- Potresti scriverlo tu! - Potresti scriverlo tu il nuovo libro sul mocking e sul testo in un po'.- Carita! Io già faccio fatica a capire che cosa fa il framework di Mocking che mantengo, che è l'altro dei miei balocchi, siccome non ne parlo mai.Io mantengo un framework di Mocking, si chiama OK, è molto bello, ha un sacco di show aperti.Per favore aiutatemi.Tra l'altro, tra l'altro utilizzato dai grandi, ho visto, no? Eh sì, ho avuto questo momento, adesso non spoilerò i miei recenti cambiamenti di carriera, ma Stavo parlando con una persona di Google e mi ha detto "guarda, sai cosa ho fatto? Guarda, refresca la pagina della documentazione ufficiale di Android e nella documentazione ufficiale di Android, negli strumenti consigliati per il testing, c'è il mio framework di mocking".Questa è una delle cose che mi hanno terrorizzato di più nella vita, assieme a scoprire che lo usa la gente di AWS e che ci sono pezzi che usano il mio framework dentro Spring.Quindi io ho scritto del firmware.Per fortuna non l'ho scritto tutto io, in realtà io poi la storia, il gruppo Telegram la sa sono diventato maintainer dopo.Ma comunque io mantengo del codice usato in dei posti veri dell'internet.E ti siamo riconoscenti per questo? Io per fortuna non ne ho alcuna responsabilità.è bello no? quando c'è quella riga nella licenza il codice è distribuito così senza nessuna garanzia tutela il codice è distribuito e adesso sono cazzi tuoi esatto io ho alcuni balocchi il primo è una cosa di cui avrei voluto parlare ma visto il tempo non abbiamo avuto modo che è Gherkin che è una cosa fighissima e credo che ne parleremo prossimamente perché è una roba che a me gaza tantissimo.È un linguaggio possiamo chiamarlo così e fondamentalmente scrivere i test end to end in inglese e quindi un modo particolare per scrivere i test non vi aggiungo altro io l'ho usato tanti anni fa con Behat su PHP tanti tanti tanti cuori.Lo usava anche il team di QA di Kijiji.Bellissimo.In cosa lavoravate? PHP.Quando io dico che nonostante lo disprezzi PHP mi ha pagato la spesa all'S lunga diverse volte era quel periodo lì della mia vita.No è bellissimo in realtà perché io Io lo utilizzavo quando lavoravo nella mia azienda ed era un ottimo modo per shareare la knowledge tra produttor e owner e per avere un documento formalizzato dove ci scambiavamo veramente e formalizzavamo veramente le feature.Quindi questo è uno dei micro balocchi.Poi durante l'episodio vi ho ho parlato di chromatic che è un servizio che fondamentalmente dà i superpoteri a storybook fatto dallo stesso team che fa storybook.Storybook è quel tool che permette di esporre i componenti sia che li scrivi a te per angular, react, vuejs, chi più ne ha più ne metta.La cosa interessante di chromatic è che ci aggiunge delle feature per far lavorare in gruppo fondamentalmente e ha una cosa fighissima che il visual regression testing quindi quello strumento che ti dice ok questo è cambiato di tre pixel in questo modo guarda che forse il tuo UI ti sta per saltare a saltare il collo che è comunque molto molto figo se ne avete la possibilità buttateci un occhio e poi l'ultimo balocco di oggi è l'episodio numero 25 dove parliamo dove parlo era uno dei primi episodi si parla di giugno del 2020 è passato un po di tempo è quasi due anni ahimè e si parla di di cypress ma si parla soprattutto di testing, di piramide, di clessidra, di cono gelato e sono i vari modi di vedere l'approccio al testing.Se sentite un me un po' impacciato ricordatevi che la puntata numero 25 e attualmente siamo tipo alla 113.Eri giovane.Esatto, giovane spensierato.E' arrivato il momento di ringraziare chi ci supporta in questo progetto perché grazie a voi che ogni giovedì riusciamo ad uscire con un nuovo episodio del nostro podcast e anche questa settimana abbiamo due supporter che ci offrono una birra e quindi ci permettono di far fronte a tutte o almeno una parte delle spese che github sostiene per arrivare fino alle vostre orecchie quindi questa settimana dobbiamo ringraziare due mega donatori il primo è luca del pupo grazie luca che ci scrive anche un messaggio donandoci tre birre grazie ragazzi per il valore che portate per lo sforzo e l'energia che ci mettete per la compagnia che mi fate durante le passeggiate o nei tragitti in macchina Grazie a te Luca, grazie della donazione e grazie del bellissimo messaggio Abbiamo anche un altro donatore Che ci invita una birra è Matteo Candura che però non ci ha lasciato messaggio quindi Matteo se ci senti mi raccomando Scrivici nel gruppo telegram e mandaci anche a cagare, ne hai il diritto Adesso che sei un supporter Scherzi a parte, io voglio ringraziare nuovamente Matteo e Luca perché attraverso la loro donazione noi riusciamo a sostenere tutte a supportare tutte le spese che il podcast comporta Niente, quindi detto questo solleviamo il calice come è nostro solito fare in aria e brindiamo alla salute di Matteo e di Luca Grazie detto questo io ringrazio il nostro kindle test io sono io che ringrazio te perché dai spazio ai miei sprolocchi sulla London School bellissimo io rimando a se ci va un fare una puntata un un bababababababa...sai cosa pensavo e lo dico in diretta? Telegram ha la chat vocale no? Quindi magari ci organizziamo se qualcuno vuole fare la guerra tra London School e Chicago School ci organizziamo una pausa pranzo, 15 minuti di guerra col timer e ci divertiamo sul flaming.Beh così io finalmente posso dire che uso i moc per riconoscenza.Questo è forse l'inside joke degli inside joke di Goodwar.Pensa alla gente che ascolta questa puntata senza averne mai ascoltate altre e dice "ma cosa cazzo dice?" Esatto, no no ma ormai i nostri ascoltatori sono belli fidelizzati.Anche se devo dire che ci sono circa 400/500 ascoltatori che non sono ancora nel gruppo Telegram E questo è male! Medi, quindi possono essere qualcuno in più Quindi potenzialmente il gruppo Telegram è di ben più di 1000 persone Dovrebbe essere decisamente più di 1000 persone persone.Quindi siamo...questo vi abbiamo spoilerato anche i numeri del podcast, stiamo crescendo e siamo veramente felici di queste...A quante persone possiamo indire un referendum? Penso che non ci siamo ancora ma con lo sforzo...quanto è? 100? Possiamo tipo non lo so abrogare php della costituzione italiana o una roba del genere.Ok ok adesso parte il flame.Io vi ringrazio di nuovo un abbraccio grandissima Mattia grazie per averci raccontato le cose che ti piacciono e alla prossima ciao abbracci ciao ciao GitBar il circolo dei fullstack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
