Gitbaritalian
developer
podcast
25

Sviluppo web e testing. Cosa cambia con Cypress.io

Serie 1
Episodio 25
Durata 40 minuti

Il testing è una fase importantissima dello sviluppo web, specie se si tratta di programmare applicazioni il cui livello di complessità non è triviale.

Esistono vali modi per approcciare al testing di una applicazione, in questo episodio vi racconto quello che intendi applicare nel mio nuovo progetto.

Lo farò usando cypress uno scintillante tool che semplifica la vita dello sviluppatore e offre out of the box funzionalità indispensabili per una suite di test moderna.

Links

Contatti

@brainrepo su twitter o via mail a info@gitbar.it

Crediti

Le sigle sono state prodotte da MondoComputazionale Le musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

benvenuti su bar di podcast dedicato al mondo dei full stack developer di mezzo artigiani, mezzo artisti che ogni giorno infilavano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo bene e benvenuti.
Ventitreesima puntata di bar.
Prima di iniziare a parlare di un argomento molto interessante che appunto il mondo del testi, mi premeva in modo molto rapido ricordarvi i nostri contatti, potete scrivermi a settembre il repo sul twitter o ha infuso appunto Edith mi raccomando, scrivetemi perché sono curioso di sapere intanto cosa ne pensate del podcast e poi perche' no, se c' è qualche argomento che volete approfondire.
Detto questo, senza perdere ulteriore 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 portato in questi casi è quella che quando tu sviluppi la tua suite di testa non si è pagato per farlo, nel senso che lo strumento di misura che il tuo cliente utilizza per pagarti per pagarti quanto sono le il il testo è spesso visto come un ponteggio nella costruzione di un palazzo tu lo vai ammontare, poi però quando finisci la realizzazione della tua struttura lo lo toglie via, per cui non ci più e 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 e' scrivere i testi 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 testa.
Quindi se da una parte e cioè il fatto che il nostro cliente non è in grado di percepire l'utilità del del testo, questo capita spesso, non un cliente che non è in grado di capirne dall'altra parte c'è anche lo sviluppo attore 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à tra 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 io scrivo il codice e da qualche parte in qualche momento questo si rompe e a quel punto ci si avvicina al mondo dei test e ci si avvicina comunque con una consapevolezza, con un approccio completamente diverso.
Se ci si avvicina con la consapevolezza che ha, non puoi conoscere tutti gli angoli e anfratti del linguaggio B, non puoi conoscere tutti i dettagli del dominio che stai andando a sviluppare, vuoi perché questi possono svilupparsi, evolversi nel tempo.
Non puoi tenere a mente tutta la logica applicativa, quindi tutta la logica del programma che si sviluppano, 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 il test il delle fasi di testing vengono fatte manualmente.
Il problema è che quando il software cresce, quindi anche crescono.
Diventa veramente impegnativo testare un processo.
Io posso portare l'esempio di un'applicazione che sviluppa i tanti anni fa, che diventò veramente mastodontica e che non aveva nessuna suite di testa, per cui ogni qualvolta si doveva andare a sviluppare un'integrazione mela era davvero un incubo.
Perche' fare tutti i test riguardanti anche se un'area circoscritta riguardante l'applicazione diventava veramente spaventoso e che ci spingeva a non farli.
Ecco l'adozione di una suite di testa ben progettata, almeno progettata bene quanto la suite applicativa permette la riduzione delle regressioni.
Cosa vuol dire? 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.
Beh, una suite di test ci può evidenziare i punti dove in realtà questa nuova evoluzione questa nuova fitch va a intaccare e che non funzionano più a quel punto semplicemente prima di andare a letto.
E poi siamo quello che c' è da fissare dei protestanti siamo riusciti a implementare nella nostra nuova funzionalità senza avere da da da paura di rompere tutto ecco che poi porta spesso, per lo meno nella mia esperienza, a un blocco di implementazione.
Quindi sei davanti al codice che sai che devi implementare una nuova funzionalità si l'ha bloccato in stallo e hai quasi paura di iniziare a scrivere codice perché in realtà quel codice potrebbe interagire con un miliardo di altre funzionalità e non riesce a tenerle tutte a mente.
Questo ti porta 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 paghera' piu' e quindi siccome il nostro è un lavoro oltre che una passione, dobbiamo renderlo proficuo alla al massimo tra l'altro l'implementazione di una suite di testa porta anche a una cosa molto importante che è quella di pensare prima di scrivere il codice.
Spesso siamo portati abbattere il giusto la 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 funzionalita' proprio a livello tecnico a livello di funzionalità di codice da utilizzare a scrivere un testo ti costringe a entrare nel meccanismo di rifletterci prima di di scrivere una certa classe.
Una certa funzione, quindi in qualche modo ti accompagna verso l'approccio in festa.
Certo è che i vantaggi dello scrivere il codice tra l'altro esiste un'ampia ampia ampia letteratura in merito, quindi magari qualche lo metto nelle note dell'episodio.
Però tra i vantaggi di scrivere una su una buona suite di testa è quella che va a supporto.
Insomma, il fatto che comunque è una cosa positiva per la prende reputation perche' perche' La nostra realizzazione del prodotto si basa sulla fiducia che noi costruiamo la fiducia e la credibilità che ne 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 con il nostro cliente, 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 ti la credibilità e la fiducia che noi costruiamo.
Il nostro è utente proprio attraverso lo sviluppo del sol del del software si trasforma molto, molto facilmente in denaro.
E siccome lo ripeto ancora una volta per noi fare gli sviluppatori e fu è 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 è importante sviluppare la nostra suite di testa.
Quindi e'.
Avere una buona suite di testa vuol dire vedere gli errori prima che li veda.
Il nostro utente, 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.
E anche positivo perché evita di costruire sugli errori.
Immaginate di dover costruire un palazzo e di aver fatto un pilastro portante.
È perché in realtà a dei deficit che potrebbe crollare da un momento all'altro e su quel pilastro portante ci avete sviluppato quattro piani 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, eh? Intervenire prima di costruire degli altri piani, probabilmente del palazzo, non crolla.
Se invece trascurate questo fatto, le trascuriamo questo.
Affatto.
Il palazzo viene giù un'altra cosa importante che io ci tengo sempre a evidenziare che fare una buona suite di testa vuole anche dire provare, immaginare tutti i casi limite che si possono ha in qualche modo che possono in qualche modo verificarsi all'interno delle esecuzioni nel nostro software, eh? Portare la mente a immaginare i casi limite probabilmente fa sì che nel momento in cui quel caso limite si' si verifica, noi abbiamo già sviluppato delle delle delle soluzioni che ci permettono di non far crollare il nostro.
Il nostro palazzo tra l'altro fare i test vuole anche dire costruire una buona documentazione partendo dal presupposto che in realtà una buona uscita di testa, specie se si parla di testa di accettazione, e' anche un buon punto di partenza o 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 sui di teste 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 prede per lui che sono una delle cose è che in qualche modo attanagliano lo sviluppo di un prodotto.
Beh, avere una buona suite di teste ci permette di da una parte sviluppare una klein di continuo di liberi e quindi permettere di andare in produzione nel minor tempo possibile con la maggior tranquillità, perché sai che le esecuzioni in testa automatiche automatici che girano in una finestra di tempo molto ridotta che può andare da il minuto hai quindici minuti, ti permette di andare in di lui in modo sereno e soprattutto veloce perche' se quei test dovessi farle amano probabilmente so ci vorrebbe molto piu' tempo, quindi certo è che il testing non è divertente, ma ti rendi conto che ci serviva proprio nel momento in cui non ce l'hai, quindi ne capisce nel momento in cui ti manca, specie se in realtà non realizzi dei progettino che poi dopo un anno devi andare a buttare giu' nel cestino eh? Non devi sviluppare ulteriormente, ma quando invece inizia a sviluppare dei progetti un pochino più ciccio, quindi un pochino più, più più grossi che hanno come proprio come come prospettiva di vita, un lasso di tempo un pochino più lungo beh, a quel punto sviluppare una suite di testa eh è un buon investimento.
Non è più come sviluppare un tirare su un ponteggio per un palazzo, ma e' 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 turchi utilizziamo.
Buona parte di tour che utilizziamo per fare il testing non sono un sexy, quindi non sono diciamo attraenti.
No, io posso pensare che ne so un selenio che ti fa impazzire in fase di configurazione o o comunque una serie di tool che in realtà non sono dal mio punto di vista divertenti pero'.
Diciamo che spesso questa mancanza, appunto di sex appeal da parte degli 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 di Mike con Spero si si pronunci moon.
Un concetto che appunto questo questo sviluppatore ha raccontato nel suo libro su Il il.
Il concetto di 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 testa 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 Tess, che noi facciamo a ogni minimo componente del nostro sviluppo, che naturalmente componente adottato 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 singola responsabilità per cui ogni elemento del nostro software che sia essa funzione, ho classe a una singola responsabilità.
A quel punto, attraverso un approccio appunto di unit testing, riusciamo a testare in modo isolato.
Per nel mondo del test si sprecano le fazioni e le le le filosofie politiche.
In realtà nel ci sono due fazioni, diciamo che si scontrano una e che prevede lo sviluppo degli unit test sociale.
Quindi cosa vuol dire quando io ho una funzione o una classe comunque un'unità di codice, chi utilizza anche delle dipendenze esterne? Io coinvolgo queste dipendenze nella nel testo.
Altri invece dicono che Sting è 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 vogliamo testare ebbe devono essere in qualche modo sostituite con degli attori, degli oggetti finti chiamati moka instabile.
E questi questi oggetti su questi oggetti vanno a simulare la risposta di un oggetto esterno, senza però eseguirne il comportamento.
E 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 testa sarà inferiore rispetto ai sanitari.
Troviamo i test di integrazione.
Come vi dicevo, la quantità di teste di integrazione, senza dubbio inferiore ai testoni unitaria e' questo il testo 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 il cazzone dell'applicazione che stiamo andando a sviluppo.
Il livello più alto della è il testing hand to hand, dove per testing intende il testo della nostra applicazione web, in questo caso nella sua interezza.
Quindi gli possiamo immaginare quasi l'omino del test in che va a compilare il form si s'iscrive nella nostra applicazione prova le funzionalità.
Ecco, questo può essere identificato in modo molto semplicistico come test hand duende.
Vero è che questo approccio è l'approccio utilizzato per lungo tempo, però spesso mi sono trovato a fare i conti con quella che in gergo tecnico viene chiamata la testa ai rami dai scream, cioè il gelato che cos'è il gelato, semplicemente la piramide che vi ho raccontato, non dove la parte alta, quella dei testi in tua anche solo uno di numero decisamente più ridotto rispetto agli teste.
E sopra questa piramide ci sta una nuvoletta che è il nostro gelato, la 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 punto di vista in dopo che aver fatto gli uni testo in testa verrà testato.
Anche ciò che non andavate è stato quindi una cosa importante che evidenzia sempre testare sì, ma cio' che va testato e 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 piu' volte lo stesso blocco di codice, quindi a fare una sovra lavoro che poi, a livello proprio ddd produttivo mi portava a spendere tante ore di testing testing già fatti e quindi a sprecare semplicemente le risorse per ovviare a questo problema.
Da qualche tempo, anzi quest'ultimo progetto che sto realizzarlo sto cambiando un attimino 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 e costruire una rete anticaduta per il nostro software.
Per cui il test in e il testing diary di codice già coperte a testi indeed da test in quello e' superfluo.
Il mio obiettivo è proprio quello di andare a sfrondare, eliminare queste queste queste aree sovra coperte per ottimizzare appunto la quantita' di test realizzati.
Per farlo sto completamente stravolgendo il mio approccio al testing, sto anche utilizzando una suite di testa nuova che ho scoperto da relativamente poco, che si chiama sai prese di cui vi parleremo poi tra qualche minuto però prima di parlare della suite di testa e parlo dell' approccio al testing.
Intanto sto iniziando a introdurre ho iniziato a introdurre nel mio stack l'inter introdurre un mi permette di verificare il codice prima ancora di andarlo a eseguire.
Una cosa come funziona questo piccolo stacco che sta implementando perché ormai uso da tanti anni e che mi aiuta a rendere il codice più leggibile.
Comprensibile.
Perché? Perché in realtà, se noi teniamo il codice con una leggibilità alta, quindi un codice di una qualità, abbastanza riusciamo a identificare prima gli errori e riusciamo anche a intervenire in modo più rapido su questi.
Se poi scendiamo di livello, troviamo se l'inter che ci permette di capire la struttura del codice e per esempio ci dice se stiamo usando una variabile che non è definita e quindi identifica in questo tipo di problemi a priori e ci aiuta a già in fase di sviluppo.
Su questo, tra l'altro e utilizzo un altro livello che si chiama Ty E' cieca che cosa è praticamente un po'? Come usare types script senza script? Cosa fa? Va a verificare tutti gli errori di tipo sulle sulle sulle variabili e quindi ci controlla anche possibili conflitti in termini appunto di tipi di variabile.
Ci elimina un'altra grande parte di errori a priori.
Una volta che utilizzato questo approccio e ho eliminato tutti quelli che ho buona parte di quelli che sono e i thai o no nello nella scrittura del codice cosa hanno? Un approccio che parte dalle stories se prima mi andava blocca attestare per blocchetto con gli unit test a priori.
Adesso sto provando a partire dal stories, quindi faccio non una i miei test hand to hand eseguo, gli faccio funzionare, quindi scrivo il codice e verifico che i test hand to hand e funzioni.
Una volta che ho fatto questi test hand tu nn ho installato istanbul.
Cosa fai Istanbul semplicemente verifica il dei miei testa quindi non fa altro che andare a controllare quali righe di codice vengono eseguite dalla mia suite di testa.
In questo caso di testa hand stupenda è un andando a verificare quali league e sono coperte mi restituisce una percentuale di code coverage.
Però attenzione avere nello una cosa che vedo spesso da colleghi è quello di cercare di raggiungere la copertura dei test ha più vicina al cento per cento.
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 cold cover, portare questo accordo al cento per cento, dove non vi nascondo che per diverso tempo fa è stato uno dei miei obiettivi.
Perché naturalmente avere una suite di test che copre il cento percento delle tue righe di codice ti rende figo.
In realtà l'affermazione più che discutibile.
Invece questa volta vorrei usare la povera, quindi report medico di per andare a esplorare quelle che sono le linee non toccate dalla testa.
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 un'interfaccia ben integrata non vengono toccate che ne sono sono dei party, quindi andare a incidere su queste col testo unitario.
A quel punto io ho testato al cento per cento la mia applicazione senza ripetermi e fare testa sul test su test, quindi cercando di tenere più snella possibile la mia suite di testa, ma comprende abbastanza da poter in qualche modo tutelare la la la mia applicazione nel momento in cui poi la vado a implementare.
Vero è che se ci sono dei piccoli processo dei processi dove la logica di business è importante, potrebbe fallire.
Io al test Wendell, quindi al testo di alto livello che simula il comportamento dell'utente ci metto anche una piccola suite di testo unitario ed integrazione.
Però ripeto, sono mirate su quella dove voglio più intensificare il testing, perché intanto già con questo approccio riesco a cup ride buona parte della mia applicazione.
Naturalmente non so se questa se questa questo approccio e sarà premiante nel tempo, però ah, ragionando a rigor di logica dovrebbe poterlo essere.
Naturalmente in questo progetto devo sviluppare quel tipo di esperienza.
Quindi magari da questo punto di vista rimanda a un appuntamento successivo, magari tra tra qualche anno, anche con la speranza che il podcast si abbastanza longevo e e rimanda 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, in realtà appena raccontato l'approccio che voglio adottare per quanto riguarda il destino di questo nuovo progetto, ma per farlo devo utilizzare lo intendo utilizzare uno strumento.
Prima vi ho detto che spesso le nostre.
I nostri tool che utilizziamo per il testing non sono sexy in qualche modo naturalmente qua scatena le iridi buona parte dei colleghi, però comunque diciamo che in realtà questo non si presenta non come uno strumento figo, con un buon sex-appeal.
A parte un tool che è stato presentato qualche tempo fa e che si chiama sai, prescrive in qualche modo veste gli abiti del tuo tipico del mondo nel mondo javascript in realtà di cosa si tratta? Si tratta di un motore per il test ha basato su ed essere quindi su un'istanza di cromo che gira naturalmente, cioè anche i noodles.
E sotto che si occupa appunto di interagire col sistema operativo che fa vaccinare direttamente all'interno di questo usare i nostri test naturalmente è agnostico, quindi non almeno per quanto riguarda i test in e non gli interessa.
Stack è stato sviluppato naturalmente se parliamo sui testi, intuendo se invece scendiamo altri livelli.
Bee si basa prevalentemente su, ma lo vedremo tra pochissimo e in realtà ci permette di testare tutto ciò che può girare su browser, che sia essa una funzione, una classe Che senso ha un componente? Vedi che nei suoi componenti di relax a Un'altra, applicazione scritta alleato in piu' o in Angola, ci permette di testare delle piaghe.
Ci permette di simulare in realtà il l'utente, come facevo con con selenio, quindi simulando proprio dell'utente dalle clicca e alla navigazione e persino fino ad arrivare appunto al drag queen troppo.
Ci permette inoltre una cosa che ho riconosciuto come molto molto interessante e ci permette di eseguire dei test di accessibilità attraverso l'uso di Axl, quindi di vedere che ne so si' un fonte piccolo se il colore su quel colore e genera dei problemi di accessibilità e insomma è veramente interessante tra l'altro una delle sue.
Uno dei suoi vantaggi è quello di essere estensibile si installa in un modo facilissimo e semplicemente un pacchetto di npl che devi installare in modo globale.
Quindi mo' guarda veramente veramente semplice e ci permette di scoprire di avere un tool per fare il cento per cento, specie se sviluppiamo un'applicazione Java script il cento percento del testing full framework o quindi ci permette di testare dalla logica di server attraverso appunto le aio di questo tipo a ai componenti e quindi in qualche modo ci permette con un solo tool di di creare appunto quella rete sotto il nostro software per sviluppare tranquilli, si basa su tecnologie abbastanza stabili.
So che sai che sono delle teche, dei tool di testing che si sono ormai storicamente utilizzati nell'ambiente javascript e prima vi ho detto che è un chrome l'essere, non quindi in realta' gira sulla sulla mia macchina un'istanza di cromo.
In realtà nell'ultima versione in quattro e supportato anche microsoft edge e far fox con cypress quattro però girano queste stanze, noi eseguiamo i test su questa stanze, le seguiamo direttamente sul browser senza come succedeva con selenio esserci uno scambio di dati tra il della l del testo e poi il driver di selenio che si occupava di di fare le azioni sul sul sul e vi dicevo può essere essendo headless implementato su una in di continuo integration, quindi e può essere eseguito su istanze terze e quindi liberare la nostra macchina è entrare appunto in processi di di continuo integration che snelliscono loro la sia l'approccio allo sviluppo che poi anche al di lui e a tutto il ciclo di vita.
Molto del software permette una funzione molto interessante quella di specie nei testi indù hand di registrare l'azione che tu stia andando a fare all'interno dell'applicazione sotto forma di video.
Questo è già un primo passaggio verso la probabilità.
Ricordo quando facevo i test con selenio, oltre che una configurazione da far perdere metà dei capelli della testa perché dovevi tirar su dei container, c'ha un di drive e poi ti chiedeva di fare mille configurazione.
So era una cosa impegnativa, non senza frizione.
E mi ricordo che per vedere lo stato di fallimento nel dettaglio di un certo intuendo fare tutta una serie di screenshot uno per uno invece selenio, oltre a dare la possibilità di registrare il processo appunto di di testa cosa fa esegue stasera per il test ci mette a disposizione uno strumento di time traveling dove noi possiamo cliccare su una linea specifica nel nostro test e verificare cosa e' successo in quella linea e magari accedendo attraverso i developer tools e la classica tendina sotto del browser che usiamo continuamente su cromo.
Quando facciamo il nostro sviluppo su fox attraverso questi developer, tutti noi possiamo fare in realtà un molto più puntuale andare individuare persino il valore delle variabili a quel modo in quel momento preciso del test.
Un livello che in realtà durante l'esecuzione di un test entro il era difficilmente raggiungibile con altri strumenti e tra l'altro.
Una cosa molto interessante è che ci immaginando completamente sul perché il codice che ranna che esegue il test era sul a fianco alla nostra applicazione e girando appunto completamente sul sul.
Noi possiamo agire a livello di software, quindi possiamo per esempio modificare lo stato tu della nostra applicazione di reati 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 testo, intuendo non fare un per ogni test, ma semplicemente forzare, simulare i luoghi in questo è un esempio, naturalmente andando iniettare all'interno dello stato, appunto l'utente e quindi ci permette di interagire in modo molto più profondo con la nostra applicazione che sentite è perché cypress è davvero affascinante.
E poi il le funzionalità appunto di de e stenderlo con una base appunto di nord.
Se sotto quindi puo' fare praticamente tutto in ambito di testing e questo mi mi mi mi entusiasma particolarmente.
Naturalmente non sono un ninjà dell'argomento quindi e voglio prendere appunto questo questo progetto che sto sviluppando e cercare di fare più esperienza possibile capire anche quelli che sono i limiti di questo è framework di testa e soprattutto quelli che sono i limiti dell'approccio di cui vi parlavo prima.
L'approccio appunto di cercare di coprire le parti e delle della mia applicazione con una bella suite di testa, ma non andare a utilizzare appunto la la la la, la, la la testa ahmed e quindi a coprire magari tutto il software di e poi andare magari a testare il testato facendo dei test hand to hand 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ù importanti, un progetto che deve andare sul cestino dopo uno o due anni.
Bene, fare una buona suite di testa è un investimento per il futuro, quindi consiglio sempre di farla.
Detto questo, io vi do appuntamento alla prossima settimana con un altro episodio di prima di salutarvi voglio ricordarvi i contatti.
Potete scrivermi su Twitter, al Brain repo o via email a punti trovate tutte le informazioni di questo episodio e degli altri nel sito www it Dove avete la registrazione dell'episodio oltre della notte dell'episodio con tutti i link e tante informazioni utili.
E se vi fa piacere e questa puntata mi e' piaciuta, aprite dal vostro client di posta e iscrivetevi in questo modo riceverete le settimanalmente la notifica di pubblicazione del nuovo episodio Se proprio proprio è questo episodio vi è piaciuto davvero tanto Bene, aprite ai toons o l'applicazione podcast 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 dal e' tutto un saluto Ciao boo-boo il circolo dei fusti che una volta a settimana ci troviamo davanti a due birre e comprerebbe.
Parliamo di linguaggi e tecniche di sviluppo web, metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei Foster, quindi
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄