Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene e benvenuti, ventitresima puntata di GITBAR.prima di iniziare a parlare di un argomento molto interessante che è appunto il mondo del testing mi premeva in modo molto rapido ricordarvi i nostri contatti potete scrivermi a @brainrepo su twitter o a info@gitbar.it mi raccomando scrivetemi perché sono curioso di sapere intanto cosa ne pensate del podcast e poi perché no se c'è qualche argomento che volete approfondire.Detto questo senza perdere ulterior tempo anche perché nelle scorse puntate mi sono dilungato abbastanza forse anche troppo andiamo subito ad affrontare l'argomento di oggi che è appunto il testing.Testare una palla questa frase la sento spesso quando mi confronto con alcuni colleghi che di solito descrivono il processo di testing come qualcosa che rallenta il processo di sviluppo, vista un po' come una zavorra e anche abbastanza noiosa.La tesi che viene portata in questi casi è quella che quando tu sviluppi la tua suite di test non sei pagato per farlo, nel senso che lo strumento di misura che il tuo cliente utilizza per pagarti e per pagarti quanto sono le feature.Il test è spesso visto come un ponteggio nella costruzione di un palazzo.Tu lo vai a montare e poi però quando finisci la realizzazione della tua struttura lo togli via.Per cui non c'è più.È la fatica che hai fatto per montare il ponteggio e poi per toglierlo non viene percepita.Secondo me invece alla base di questo rifiuto verso i test c'è anche un elemento di tipo psicologico.c'è da dire che noi programmatori abbiamo spesso un ego abbastanza grosso e che scrivere i test vuol dire ammettere di essere infallibili quindi vuol dire mettere in discussione le proprie capacità ogni volta in ogni riga di codice che scriviamo e questo secondo me influisce nella decisione di non adottare una suite di test quindi se da una parte c'è il fatto che il nostro cliente non è in grado di percepire l'utilità del test.Questo capita spesso, un cliente che non è in grado proprio di capirne l'importanza.Dall'altra parte c'è anche lo sviluppatore che in realtà spesso dice "ma non ne ho bisogno, so che funziona, lo sto vedendo, l'ho già provato e questo l'ho già provato che in realtà trae in confusione.Quando si fa quel passo avanti per cui diciamo che si sviluppa la consapevolezza di quasi non fidarsi di se stesso perché tanto tu scrivi il codice e da qualche parte in qualche momento questo si rompe, beh a quel punto ci si avvicina al mondo dei test e ci si avvicina con una consapevolezza con un approccio completamente diverso ci si avvicina con la consapevolezza che A) non puoi conoscere tutti gli angoli e gli anfratti del linguaggio B) non puoi conoscere tutti i dettagli del dominio che stai andando a sviluppare vuoi perché questi possono svilupparsi e evolversi nel tempo non puoi tenere a mente tutta la logica applicativa quindi tutta la logica del programma che stai sviluppando anche perché spesso la logica si complica e non puoi conoscere profondamente appieno il codice scritto dagli altri.Quindi partendo da questi quattro assunti il test diventa uno strumento per costruire dei parapetti e non precipitare nel momento in cui tu scrivi la tua applicazione.vero è che in realtà spesso le fasi di testing vengono fatte manualmente il problema è che quando il software cresce quindi anche le feature crescono diventa veramente impegnativo testare un processo.Io posso portare l'esempio di un'applicazione che sviluppai tanti anni fa che diventò veramente mastodontica e che non aveva nessuna suite di test per cui ogni qual volta si doveva andare a sviluppare un'integrazione, beh, là era davvero un incubo perché fare tutti i test riguardanti, anche se un'area circoscritta, riguardanti applicazioni diventava veramente spaventoso e ci spingeva a non farli.Ecco, l'adozione di una suite di test ben progettata, almeno progettata bene quanto la suite applicativa, permette la riduzione delle regressioni.Cosa vuol che quando noi andiamo a sviluppare dei blocchi nuovi che attacchiamo al nostro software spesso qualcosa si rompe del vecchio codice per evitare di non spaccare questi elementi, una suite di test ci può evidenziare i punti dove in realtà questa nuova evoluzione, questa nuova feature va a intaccare e che non funzionano più a quel punto, semplicemente prima di andare a deploy, fixiamo quello che c'è da fixare e praticamente siamo riusciti a implementare la nostra nuova funzionalità senza avere quell'ansia da paura di rompere tutto che poi porta spesso, perlomeno nella mia esperienza, a un blocco di implementazione quindi sei davanti al codice che sai che devi implementare una nuova funzionalità e sei là bloccato, installo e hai quasi paura di iniziare a scrivere codice perché in realtà quel codice potrebbe interagire con un mila miliardo di altre funzionalità e non riesce a tenerle tutte a mente.Beh questo ti porta a una stasi.Quella stasi vuol dire tempo nel quale non fai niente fissi lo schermo e quindi tempo improduttivo tempo che in realtà il cliente potrebbe pagarti una due tre volte ma poi non ti pagherà più e quindi siccome il nostro è un lavoro oltre che una passione dobbiamo renderlo proficuo al massimo.Tra l'altro l'implementazione di una suite di test porta anche a una cosa molto importante che è quella di pensare prima di scrivere il codice.Spesso siamo portati a battere giù sulla tastiera compulsivamente appena ci viene un'idea e quindi abbiamo oltre che una mancanza di progettazione anche una mancanza di pensiero su come sviluppare una certa funzionalità proprio a livello tecnico a livello di funzionalità di codice da utilizzare.Lo scrivere un test ti costringe a entrare nel meccanismo di rifletterci prima di scrivere una certa classe una certa funzione quindi in qualche modo ti accompagna verso l'approccio think first.Certo è che i vantaggi dello scrivere codice tra l'altro esiste un'ampia ampia ampia letteratura in merito quindi magari qualche link la metto nelle note dell'episodio però tra i vantaggi di scrivere una buona suite di test è quella di che va a supporto insomma il fatto che comunque è una cosa positiva per la brand reputation perché perché la nostra realizzazione del prodotto si basa su una fiducia che noi costruiamo una fiducia, una credibilità che noi costruiamo con il nostro utente.Se noi andiamo a intaccare questo livello di fiducia a quel punto andiamo a distruggere o danneggiare quello che è il rapporto col nostro cliente e quindi quella che è la possibilità di un potenziale sviluppo del prodotto, di un potenziale guadagno se appunto stiamo sviluppando un prodotto o di un potenziale altro altro progetto se parliamo di un cliente quindi nella nostra azienda nei nostri progetti la credibilità e la fiducia che noi costruiamo col nostro utente proprio attraverso lo sviluppo del software si trasforma molto molto facilmente in denaro e siccome lo ripeto ancora una volta per noi fare gli sviluppatori e full stack dev è una professione l'elemento comunque denaro è importante cioè non stiamo giocando non stiamo facendo il nostro side project che potremmo mettere nel cestino e anche in quello credetemi è importante sviluppare la nostra suite di test quindi avere una buona suite di test vuol dire vedere gli errori prima che li vede il nostro utente e fixarli quindi vuol dire portare al nostro utente un numero minore possibile di errori e questo è senza dubbio un vantaggio tra l'altro trovare gli errori per tempo è anche positivo perché evita di costruire sugli errori immaginate di dover costruire un palazzo e di aver fatto un pilastro portante che in realtà ha dei deficit che potrebbe crollare da un momento all'altro e su quel pilastro portante ci avete sviluppato quattro piani di palazzo.Beh certo è che se aveste avuto una suite di test per verificare che quel pilastro era danneggiato o comunque non poteva sostenere quel peso e intervenire prima di costruire gli altri piani probabilmente il palazzo non crolla.Se invece trascurate questo fatto, e trascuriamo questo fatto, il palazzo viene giù.Un'altra cosa importante che io ci tengo sempre a evidenziare è che fare una buona suite di test vuole anche dire provare a immaginare tutti i casi limite che si possono in qualche modo possono in qualche modo verificarsi all'interno dell'esecuzione del nostro software e portare la mente e immaginare i casi limite probabilmente fa sì che nel momento in cui quel caso limite si verifica noi abbiamo già sviluppato delle soluzioni che ci permettono di non far crollare il nostro palazzo.Tra l'altro fare i test vuole anche dire costruire una buona documentazione partendo dal presupposto che in realtà una buona suite di test specie se si parla di test di accettazione è anche un buon punto di partenza di comunicazione una bella struttura di comunicazione tra noi e il nostro cliente e quindi oltre che come vi dicevo prima l'importanza di costruire un rapporto di fiducia tra noi e l'utente del software che stiamo andando a realizzare avere una buona suite di test ci permette di costruire un ottimo rapporto di fiducia col nostro cliente o comunque una buona base per poterlo costruire e una buona base anche per eliminare le ansie da pre deploy che sono una delle cose che in qualche modo attanagliano lo sviluppo di un prodotto.Beh avere una buona suite di test ci permette di da una parte sviluppare una pipeline di continuous delivery e quindi permettere di andare in produzione nel minor tempo possibile con la maggior tranquillità perché sai che le esecuzioni di test automatici che girano in una finestra di tempo molto ridotta che può andare da il minuto ai 15 minuti ti permette di andare in deploy in modo sereno e soprattutto veloce perché se quei test dovessi farli a mano probabilmente ci vorrebbe molto più tempo quindi certo è che il testing non è divertente ma ti rendi conto che serviva proprio nel momento in cui non ce l'hai quindi ne capisci l'importanza nel momento in cui ti manca specie se in realtà non realizzi dei progettini che poi dopo un anno devi andare a buttare giù nel cestino e non devi sviluppare ulteriormente ma quando invece inizi a sviluppare dei progetti un pochino più cicciosi quindi un pochino più grossi che hanno come prospettiva di vita un lasso di tempo un pochino più lungo beh a quel punto sviluppare una suite di test è un buon investimento non è più come sviluppare un...tirare su un ponteggio per un palazzo ma è come scegliere i migliori materiali per rendere quel palazzo più stabile certo è che in realtà uno degli attriti che io percepisco, poi questo può anche essere messo in discussione io percepisco come più forte è quello che in realtà i tool che utilizziamo, buona parte dei tool che utilizziamo per fare il testing non sono sexy quindi non sono diciamo attraenti no io posso pensare che ne so a un selenium che ti fa impazzire in fase di configurazione o comunque a una serie di tool che in realtà non sono dal mio punto di vista divertenti però diciamo che spesso questa mancanza appunto di sex appeal da parte degli strumenti ripagata in termini di utilità.Una delle strategie che ho sempre utilizzato nello sviluppo dei test era quello di rifarmi al concetto di "Testing Pyramid" di Mike Kuhn, spero si pronunci così, un concetto che appunto questo sviluppatore ha raccontato nel suo libro su Siting with Agile.Il concetto di Testing Pyramid si basa su una metafora visuale molto semplice, una piramide dove in realtà ci sono tre livelli e questi livelli in qualche modo vogliono raggruppare i test a seconda della loro granularità.Quindi appunto il raggruppare i test per tipo.Nella parte più bassa della piramide ci stanno i test unitari.Quindi test che noi facciamo a ogni minimo componente del nostro sviluppo che è un'attualmente componente dotato di funzionamento autonomo che andiamo a testare nella sua semplice e unica funzionalità.Tenendo presente che se sviluppiamo il nostro software con criterio e applichiamo il principio della single responsibility per cui ogni elemento del nostro software che sia essa funzione o classe ha una singola responsabilità a quel punto attraverso un approccio appunto di unit testing riusciamo a testare in modo isolato blocchetto per blocchetto nel mondo del test si sprecano le fazioni, le filosofie, le politiche in realtà nello unit testing ci sono due fazioni diciamo che si scontrano una è che prevede lo sviluppo di unit test sociale quindi cosa vuol dire quando io ho una funzione o una classe comunque un'unità di codice che utilizza anche delle dipendenze esterne io coinvolgo queste dipendenze nel test altri invece dicono che l'unit testing è un processo che deve essere sviluppato in qualche modo tra virgolette modo solitario quindi in isolamento per cui tutte le dipendenze esterne alla classe o alla funzione che vogliamo testare devono essere in qualche modo sostituite con degli attori degli oggetti finti chiamati mocha e stub.Questi oggetti vanno a simulare la risposta di un oggetto esterno senza però eseguirne il comportamento questo a livello di unit test se noi saliamo di un livello la piramide naturalmente si restringe quindi questo vuol dire che anche la quantità di test sarà inferiore rispetto ai test unitari troviamo i test di integrazione come vi dicevo la quantità di test di integrazione senza dubbio inferiore ai test unitari e questi test servono per fare in modo per verificare che tutte le componenti del nostro software lavorino bene in cooperazione.Quindi coinvolge le componenti e l'integrazione appunto tra tutti gli elementi della nostra applicazione, dell'applicazione che stiamo andando a sviluppare.Il livello più alto della Testing Pyramid è il Testing End-to-End, dove per Testing End-to-End si intende il testing della nostra applicazione web, in questo caso, nella sua interezza.Quindi possiamo immaginare quasi l'omino del testing che va a compilare il form, si iscrive nella nostra applicazione, prova le funzionalità.Ecco questo può essere identificato in modo molto semplicistico come test end-to-end.vero è che questo approccio è l'approccio che ho utilizzato per lungo tempo però spesso mi sono trovato a fare i conti con quella che in gergo tecnico viene chiamata la testing pyramid ice cream cioè il gelato.che cos'è il gelato? semplicemente la piramide che vi ho raccontato dove la parte alta quella dei test in 2N che sono di numero decisamente più ridotto rispetto agli integration test e gli unit test.Sopra questa piramide ci sta una nuvoletta che è il nostro nostro gelato e là ci sono tutti i test manuali.In realtà spesso capita di trascurare alcune aree del testing e quindi di tenere scoperto una parte del nostro software.Tenere scoperto magari dal dal punto di vista end to end dopo aver fatto unit test e unit test e aver testato anche ciò che non andava testato.Quindi una cosa importante che io evidenzio sempre è testare sì ma ciò che va testato.Non necessariamente tutto va testato.Cosa va testato? Tutto ciò che potrebbe fallire.Questa deve essere la linea guida.Però mi sono ritrovato nella mia esperienza a testare più volte lo stesso blocco di codice quindi a fare un sovralavoro che poi a livello proprio di produttivo mi portava a spendere tante ore di testing su testing già fatti e quindi a sprecare semplicemente le risorse per ovviare a questo problema da qualche tempo anzi quest'ultimo progetto che sto realizzando sto cambiando una timino strategia e quindi utilizzo una tecnica diversa non so se migliore o peggiore delle tecniche precedenti che utilizzavo però comunque una tecnica diversa che vuole in qualche modo pensare al testing per il suo obiettivo non per farlo tanto per fare cioè l'obiettivo del testing è costruire una rete anticaduta per il nostro software per cui il testing compulsivo e il testing di aree di codice già coperte da test quello è superfluo.Il mio obiettivo è proprio quello di andare a sfrondare e eliminare queste queste queste aree sovracoperte per ottimizzare appunto la quantità di test realizzati.Per farlo sto completamente stravolgendo il mio approccio al testing.Sto anche utilizzando una suite di test nuova che ho scoperto da relativamente poco che si chiama Cypress e di cui vi parlerò poi tra qualche minuto.Però prima di parlare della suite di test parlo dell'approccio al testing.intanto sto iniziando a introdurre o ho iniziato a introdurre nel mio stack un linter.Introdurre un linter mi permette di verificare il codice prima ancora di andarlo a eseguire.E' una cosa...come funziona questo piccolo stack che stai implementando? Beh Prettier che ormai uso da tanti anni e che mi aiuta a rendere il codice più legibile e comprensibile.Perché? Perché in realtà se noi teniamo il codice con una leggibilità alta, quindi un codice di una qualità abbastanza alta, riusciamo a identificare prima gli errori e riusciamo anche a intervenire in modo più rapido su questi.Se poi scendiamo di livello troviamo ASLinter che ci permette di capire la struttura del codice e per esempio ci dice se stiamo usando una variabile che non è definita quindi identifica questo tipo di problemi a priori e ci aiuta a fixarli già in fase di sviluppo.Su questo tra l'altro utilizzo un altro livello che si chiama TS check.Che cos'è? Praticamente un po' come usare TypeScript senza TypeScript.Cosa fa? Va a verificare tutti gli errori di tipo sulle variabili e quindi ci controlla anche possibili conflitti in termini appunto di tipi di variabile e ci elimina un'altra grande parte di errori a priori.Una volta che ho utilizzato questo approccio e ho eliminato tutti quelli che o buona parte di quelli che sono i type nella scrittura del codice, sto usando un approccio che parte dalle user stories se prima mi andava a bloccare a testare blocchetto per blocchetto con gli unit test a priori adesso sto provando a partire dalle user stories quindi faccio i test end to end e li eseguo e li faccio funzionare quindi scrivo il codice e verifico che i test end to end funzioni.Una volta che ho fatto questi test end to end ho installato Istanbul.Cosa fa Istanbul? Semplicemente verifica il code coverage dei miei test quindi non fa altro che andare a controllare quali righe di codice vengono eseguite dalla mia suite di test in questo caso di test end to end.andando a verificare quali lighe sono coperte mi restituisce una percentuale di code coverage però attenzione avere una cosa che vedo spesso da colleghi è quello di cercare di raggiungere la copertura dei test più vicina al 100%.Prima però ho detto una cosa più importante che dobbiamo concentrarci sul testare le cose che potrebbero fallire.Quindi al posto di andare a cercare di raggiungere questa code coverage, portare questa code coverage al 100% dove non vi nascondo che per diverso tempo è stato uno dei miei obiettivi perché naturalmente avere una suite di test che copre il 100% delle tue righe di codice ti rende figo in realtà affermazione più che discutibile invece questa volta vorrei usare la Code Coverage quindi il report di Code Coverage per andare a esplorare quelle che sono le linee non toccate da test.Quindi andare a identificare dove non sto coprendo quei test e andare a quel punto a incidere su quelle linee che in realtà magari perché ho scritto l'interfaccia ben integrata non vengono toccate che ne sono dei catch particolari, quindi andare a incidere su queste linee col test unitario.A quel punto io ho testato al 100% la mia applicazione senza ripetermi e fare test su test su test, quindi cercando di tenere più snella possibile la mia suite di test, ma coprente abbastanza da poter in qualche modo tutelare la mia applicazione nel momento in cui poi la vado a implementare.Vero è che se ci sono dei piccoli processi o dei processi dove la logica di business è importante potrebbe fallire io al test end to end quindi al test di alto livello che simula il comportamento dell'utente ci metto anche una piccola suite di test unitario ed integrazione però ripeto sono mirate su quelle aree dove voglio più intensificare il testing perché intanto già con questo approccio riesco a coprire buona parte della mia applicazione.Naturalmente non so se questo approccio sarà premiante nel tempo però ragionandoci a rigor di logica dovrebbe poterlo essere.Naturalmente in questo progetto devo sviluppare quel tipo di esperienza quindi magari da questo punto di vista rimando a un appuntamento successivo magari tra qualche anno anche con la speranza che il podcast sia abbastanza longevo e rimando appunto un appuntamento successivo dove mi piacerebbe fare un po di retrospettiva su questa scelta quindi tornare indietro e provare a vedere se la scelta è stata positiva o meno ed eccoci qua al momento feticio in realtà vi ho appena raccontato l'approccio che voglio adottare per quanto riguarda il testing di questo nuovo progetto ma per farlo devo utilizzare o intendo utilizzare uno strumento.Prima vi ho detto che spesso i nostri tool che utilizziamo per il testing non sono sexy e in qualche modo naturalmente qua scatenerò le iri di buona parte dei colleghi però comunque diciamo che in realtà questo è non si presentano come uno strumento figo con un buon sex appeal a parte un tool che è stato presentato qualche tempo fa e che si chiama Cypress che in qualche modo veste gli abiti del tool modaiolo tipico del mondo javascript.In realtà di cosa si tratta? Si tratta di un motore per i test basato su Chrome headless quindi su un'istanza di Chrome che gira naturalmente c'è anche nodes sotto che si occupa appunto di interagire poi con il sistema operativo e che fa girare direttamente all'interno di questo browser i nostri test.Naturalmente è agnostico quindi non, almeno per quanto riguarda i test end to end, non gli interessa su che stack è stato sviluppato.Naturalmente se parliamo sui test end to end.Se invece scendiamo ad altri livelli beh si basa prevalentemente su javascript ma lo vedremo tra pochissimo e in realtà ci permette di testare tutto ciò che può girare sul browser che sia essa una funzione una classe che sia esso un componente vedi che ne so i componenti di react o se la nostra applicazione è scritta in react o in view o in angular ci permette di testare delle API ci permette di simulare in realtà l'utente come faceva con selenium quindi simulando proprio l'interazione dell'utente dal click alla navigazione persino fino ad arrivare appunto al drag and drop ci permette inoltre una cosa che ho riconosciuto come molto molto interessante ci permette di eseguire dei test di accessibilità attraverso l'uso di AXE e quindi di vedere che ne so se è un fonte piccolo se il colore su quel colore genera dei problemi di accessibilità e insomma è veramente interessante tra l'altro uno dei suoi vantaggi è quello di essere estensibile si installa in un modo facilissimo è semplicemente un pacchetto di npm che devi installare in modo globale quindi guarda veramente veramente semplice e ci permette di coprire di avere un tool per fare il 100% specie se sviluppiamo un'applicazione javascript il 100% del testing full framework quindi ci permette di testare dalla logica di server attraverso appunto l'api o tool di questo tipo ai componenti front-end e quindi in qualche modo ci permette con un solo tool di creare appunto quella rete sotto il nostro software per sviluppare tranquilli.Si basa su tecnologie abbastanza stabili, Mocha e Chai, che sono dei tool di testing che sono ormai storicamente utilizzati nell'ambiente javascript e prima vi ho detto che è un chrome headless quindi in realtà gira sulla mia macchina un'istanza di chrome in realtà nell'ultima versione nella versione 4 è supportato anche microsoft edge e firefox con cypress 4 però girano queste istanze noi eseguiamo i test su questa stanza e li eseguiamo direttamente sul browser senza come succedeva con selenium esserci uno scambio di dati tra il driver del test e poi il driver di selenium che si occupava di fare le azioni sul browser.Vi dicevo può essere essendo headless implementato su una pipeline di continuous integration quindi può essere eseguito su istanze terze e quindi liberare la nostra macchina e entrare appunto in processi di continuous integration che snelliscono sia l'approccio allo sviluppo che poi anche al deploy e a tutto il ciclo di vita del software.Permette una funzione molto interessante quella di specie nei test end to end di registrare l'azione che tu stai andando a fare all'interno dell'applicazione sotto forma di video.Questo è già un primo passaggio verso la debuggabilità.Io ricordo quando facevo i test end to end con selenium oltre che a una configurazione da far perdere metà dei capelli della testa perché dovevi tirar su dei container con driver e poi ti chiedeva di fare mille configurazioni insomma era una cosa impegnativa non senza frizione mi ricordo che per vedere lo stato di fallimento nel dettaglio di un certo test Intuendo devo fare tutta una serie di screenshot uno per uno invece Selenium oltre a dare la possibilità di registrare il processo appunto di test cosa fa? Esegue step per step il test ci mette a disposizione uno strumento di time traveling dove noi possiamo cliccare su una linea specifica del nostro test e verificare cos'è successo in quella linea e magari accedendo attraverso i developer tools la classica tendina sotto del browser che usiamo continuamente su chrome quando facciamo il nostro sviluppo su firefox attraverso questi developer tools noi possiamo fare in realtà un debug molto più puntuale, andare a individuare persino il valore delle variabili in quel momento preciso del test.Un livello che in realtà durante l'esecuzione di un test end-to-end era difficilmente raggiungibile con altri strumenti.Tra l'altro una cosa molto interessante è che girando completamente sul browser perché il codice che runna, che esegue i test gira sul browser a fianco alla nostra applicazione girando appunto completamente sul browser noi possiamo agire a livello di software quindi possiamo per esempio modificare lo stato della nostra applicazione di react semplicemente con il test quindi forzare un certo stato questo ci permette tenendo presente che in realtà il codice deve essere più rapido possibile di in un test end to end non fare un login per ogni test ma semplicemente forzare simulare il login questo è un esempio naturalmente andando a iniettare all'interno dello stato appunto l'utente logato e quindi ci permette di interagire in modo molto più profondo con la nostra applicazione l'entusiasmo che sentite è perché cypress è davvero affascinante e poi le funzionalità appunto di plugin ti permettono di estenderlo con una base appunto di node.js sotto quindi può fare praticamente tutto in ambito di testing e questo mi entusiasma particolarmente naturalmente non sono un ninja dell'argomento quindi voglio prendere appunto questo progetto che sto sviluppando e cercare di fare più esperienza possibile, capire anche quelli che sono i limiti di questo framework di test e soprattutto quelli che sono i limiti dell'approccio di cui vi parlavo prima, l'approccio appunto di cercare di coprire sì le parti della mia applicazione con una bella suite di test ma non andare a utilizzare appunto la la la la test in pyramid e quindi a coprire magari tutto il software di test unitari e poi andare magari a ritestare il testato facendo dei test end to end che coprono insomma due volte la stessa la stessa funzionalità Io spero che questo episodio vi sia piaciuto anche se so che per molti il testing è una palla il mio consiglio è quello che se si vuole mandare in produzione un progettino un pochino più importante un progetto che deve andare sul cestino dopo uno due anni beh fare una buona suite di test è un investimento per il futuro quindi consiglio sempre di farla.Detto questo io vi do appuntamento alla prossima settimana con un altro episodio di Gitbar ma prima di salutarvi voglio ricordarvi i contatti.Potete scrivermi su Twitter @brainrepo o via email a info@gitbar.it Trovate tutte le informazioni di questo episodio e degli altri nel sito www.gitbar.it dove avete la registrazione dell'episodio, il transcript, le note dell'episodio con tutti i link e tante informazioni utili e se vi fa piacere e questa puntata vi è piaciuta aprite gitbar dal vostro client di posta e iscrivetevi in questo modo riceverete settimanalmente la notifica di pubblicazione del nuovo episodio se proprio proprio questo episodio vi è piaciuto davvero tanto però tanto beh, aprite iTunes o l'applicazione podcast di Apple e lasciate una recensione mi raccomando sono davvero curioso di sapere cosa ne pensate e davvero curioso di sapere cosa si può migliorare detto questo io vi do appuntamento alla prossima settimana da Lione è tutto, un saluto, ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta delle attrezzi dei fullstack dev.[Musica]
