Introduzione a Gauge
Introduzione a Gauge, un Framework per User Journey Testing.
presentato da Scott Davis. Il suo indirizzo email è scott.davis@thoughtworks.com. Il suo Twitter handle è @scottdavis99.
Istruzioni
| Scorciatoie per la tastiera | Descrizione |
|---|---|
| → o [spazio] | Diapositiva successiva |
| ← | Diapositiva precedente |
| f | F Vista a Schermo intero (alterna attiva/inattiva) |
| t | T Vista della trascrizione (in una nuova finestra) |
Di seguito alcune scorciatoie per la tastiera per aiutare la navigazione.
- Premere la freccia a destra o spazio per navigare alla diapositiva successiva.
- Premere la freccia a sinistra per navigare alla diapositiva precedente.
- Premere 'f' per attivare modalità schermo intero.
- Premere 't' per aprire la trascrizione in una nuova finestra.
Biografia
Ciao! Mi chiamo Scott Davis. Lavoro per ThoughtWorks nel ruolo di Principle Engineer. In passato ho gestito la mia agenzia di consulenza informatica in Denver, Colorado chiamata ThirstyHead.
Scrivo riguardo lo sviluppo di applicazioni web da molti anni -- articoli per IBM, libri per O'Reilly e "the Pragmatic Bookshelf", e più recentemente registro anche video per O'Reilly.
https://gauge.org/
Oggi, voglio parlarvi di Gauge, un testing framework open source e gratuito per acceptance testing.
Ma prima di inoltrarci nell'argomento, penso che sia utile definire alcuni termini in modo chiaro. Mi sentirete usare il termine "User Journey testing" spesso perché lo trovo più adatto a cosa cerchiamo di reali zzare quando usiamo Gauge. Ad ogni modo, questo tipo di testing è molto differente da quello che probabilmente utilizzate oggi in caso siat e un tipico front-end developer.
Frameworks e Unit Testing
Web framework moderni generalmente includono la loro libreria per scrivere unit test. Se siete appassionati a React, probabilmente conoscete molto bene anche Jest. Sviluppatori Angular utilizzano la libreria Jasmine per scrivere unit test.
La piramide dei test
Unit tests giocano un ruolo essenziale per creare software di qualità. Sono le fondamenta della piramide dei test. Sviluppatori web scrivono codice e questi unit test gli permettono di controllare il codice che hanno scritto. Sono tipicamente veloci da eseguire e facili da scrivere perché sono creati con l'idea di essere eseguiti isolat i da parti più complesse dell'applicazione (come esempio basi di dati e servizi web)
Spesso dico che unit test "testano i mattoni, non l'intero edificio". Dopo tutto non si può fidarci di un edifi cio se non ci fidiamo in primo luogo dei mattoni che lo compongono.
Come ci allontaniamo dal codice e ci avviciniamo agli utenti finali della applicazione (tieni questo in mente q uando iniziamo a parlare di User Journey tests) aggiungiamo più pezzi al puzzle e inevitabilmente aggiungiamo più punti dove i nostri test possono fallire.
Se la vostra organizzazione non ha un solido ambiente di integrazione -- uno che sia il più simile possibile all 'ambiente di produzione (usato dagli utenti finali), e uno che sia facile da creare e distruggere quando i test di integrazion e sono eseguiti -- questo e dove i test diventano meno comuni. Non perchè questi test sono meno importanti, ma purtroppo perch è possono essere difficili da eseguire con confidenza.
Unit Testing
Vedo un sacco di unit test che possono essere chiamati o meno veri "unit" test nel senso stretto della parola. Visto che qualsiasi test è meglio che non avere test, esito a criticare questi test che non sono corretamente es eguiti in isolamento come dovrebbero in uno scenario ideale.
Di seguito una definizione per unit test che spero tutti possiamo accettare -- unit test sono utili per lo svilu ppatore, non per l'utente finale. Nonostante ne sarei onorato, non ho mai assistito ad un utente finale chiedermi quanto codice è coperto da unit test per il sito che sto dimostrando, o quanti casi limite ho testato per "null pointer" eccezioni. Sebbene gli utenti finali beneficiano indirettamente da una solida copertura del codice tramite unit test, direi che gli sviluppatori sono i primi beneficiari degli unit test.
React Unit Testing
Di seguito un esempio riguardo cosa sto parlando. Se sviluppi una funzione 'somma' in React, quasi sicuramente avrai un unit test corrispendente per essere sicuro che il codice che hai sviluppato svolge accuratamente la funzione per cui è stato scritto. Notiamo che questa funzione 'somma' è completamente isolata dalla vista web che l'utente finale può vedere, o pe rsino da qualche altra funzione che dipende dal fatto che 1 più 2 fa 3.
Angular Unit Testing
Di seguito un altro, leggermente più realistico, esempio in Angular. Lo sviluppatore ha creato un componente 'Interruttore', e come tutti i bravi sviluppatori fanno, ha creato un co rrispondente gruppo di unit test per testare il componente in isolamento.
Dal punto di vista dell'utente finale che seleziona 'utilizza indirizzo di spedizione di default' nello schermo o la funzione 'addebita sulla carta di credito'. Senz'altro essi beneficiano dal fatto che il componente 'Interrutore' funzioni correttamente, ma quando osservia mo gli unit test è piuttosto chiaro che sono stati scritti per aiutare il prossimo sviluppatore che dovrà modificare questa pa rte del codice, non l'utente finale che effettivamente interagirà direttamente con il componente "Interruttore".
https://gauge.org/
Quindi, vi ricordate di Gauge? L'intera ragione per cui abbiamo iniziato questa conversazione in primo luogo, g iusto?
Ora che abbiamo una buona comprensione di cosa sono unit test e per chi sono scritti lasciatemi dire questo: Gau ge non sostituisce la vostra libreria unit test. Gauge è studiato per scrivere test che si concentrano sull'utente finale e non lo sviluppatore. Gauge è per scri vere User Journey test.
User Journey Test
User Journey tests sono scritti nel linguaggio dell'utente finale, non nel linguaggio dello sviluppatore. Utenti finali in genere dicono cose come, "Vorrei aggiungere pomodori nel mio carrello della spesa", e no "Vorre i aggiungere la stringa UPC dell'oggetto selezionato nella lista di stringhe nel componente Carrello".
Ora, sebbene lo sviluppatore attento possa scuotere il capo e pensare, "Meh, nel momento in cui una funzionalità è testata, il linguaggio con cui è testata è davvero così importante?"
Qui la risposta: lo è. Specialmente quando parliamo di User Journey tests. Potete chiamarli "acceptance" test, perché cosa cerchiamo di capire è come un sito sia accetabile dal punto di vista dell'utente finale. È accetabile non poter ag giugere oggetti nel carrello? È accettabile non raggiungere la pagina pagamenti e non effettuare l'acquisto?
Quindi chiamando questi test User Journey test, mettiamo l'utente finale al centro della conversazione. Questi test sono scritti nel linguaggio dell'utente finale. L'accettazione finale del progetto è alla fine eseguita dall'utente final e, non lo sviluppatore.
Design Thinking inizia con Empatia
Se chiedete ad un tipico sviluppatore quale sia il primo passo per un nuovo progetto, è probabile che vi rispond a qualcosa tipo "Scegliere un web framework" o "Inizializzare una nuova repository".
Se chiedete ad un Design Thinking fan quale sia il primo passo per un nuovo progetto vi risponderà "Empatia". Pe nsare come l'utente finale. Capire cosa voglia completare quando utilizza la vostra applicazione.
Perché se iniziate a scrivere test nel linguaggio del vostro utente finale, vi aiuterà a pensare come un utente finale. Inoltre apre la creatività di una area completamente differente del nostro cervello. "Hmmm, se compro pomodori o gni settimana, non sarebbe fantastico se potessi riacquistare lo stesso carrello della spesa della settimana scorsa?" "Sto già caricando una lista della spesa predefinita nel mio carrello della spesa per eseguire i miei unit test -- Forse farei un favo re ai miei utenti finali se potessero fare lo stesso?"
GroceryWorks
Di seguito un sito web per acquistare alimenti online chiamato GroceryWorks. Come interagite con il sito, vedete che cliccando nella sezione categorie sulla sinistra vi presenta diversi tip i di cibo -- fagioli, frutta secca, pasta, eccetera... Cliccando su un cibo lo aggiunge al carrello della spesa sulla destra. Cliccando su un cibo ancora lo aggiunge n uovamente al carrello della spesa. Cliccando su 'Acquista' vi permette di confermare o annullare il vostro ordine.
Gauge Specificazioni
User Journey tests in Gauge comprendono due parti complementari -- Specificazioni, scritte in Markdown; e tests, scritti nel linguaggio di programmazione di vostra scelta. (Più dettagli tra poco...)
Markdown è praticamente semplice testo con decorazioni come cancelletti per le testate (che rappresentano i nomi delle vostre specificazioni) e asterischi per elenchi puntati (che rappresentano i passi da compiere). Markdown fornisce la f lessibilità per esprimere i passi esattamente nel linguaggio del vostro utente finale.
Gauge Impls
Potete scrivere i vostri test in differenti linguaggi di programmazione: JavaScript, C#, Java, Python, or Ruby. Cosa vedete qui sono test scritti con una libreria Javascript sviluppata da ThoughtWorks chiamata Taiko. Sono davvero impressionato -- guardate come la sintassi è leggibile e chiara.
Probabilmente avete già osservato è che ad ogni passo in Javascript corrisponde un passo in Markdown facendo sem plicemente una comparazione delle stringhe. Semplicità è il più grande tipo di intelligenza, non credete?
Gauge Resoconti
Quando esegui i tuoi tests, Gauge produce un piacevole resoconto che dimostra quanti tests sono passati, e nel c aso falliscano, quali steps hanno causato il loro fallimento.
Conclusioni
Quindi cosa abbiamo imparato?
Frameworks and Unit Testing
Librerie per scrivere unit test sono ancora una componente fondamentale per qualsiasi sviluppatore che si rispet ti. Vogliamo che voi continuate ad utilizzare la vostra libreria preferita. Gauge non vi forza ad utilizzare una specifica libreria per unit testing perché è studiato per scrivere una cate goria di test completamente differente.
Design Thinking inizia con Empatia
Gauge vuole il tuo primo passo che sia "Empatia". Gauge vuole che tu pensi come un utente finale, perché sono coloro che alla fine decideranno se la vostra applic azione é accettabile o meno.
https://gauge.org/
Gauge è studiato per scrivere User Journey test. Catturare le parole i vostri utenti finali utilizzano ed i pass i che compiono Markdown files in Inglese. Sviluppare i test nel linguaggio di programmazione che preferite. Ottenere facili da leggere resoconti, assicurando che la vostra applicazione web faccia esattamente cosa vi aspettate.
Se scrivete di già unit test, questa è la vostra opportunità per passare al livello successivo e iniziare a pens are come il vostro utente finale e non come uno sviluppatore. Accettate la sfida?
Risorse
| https://thirstyhead.com/introducing-gauge | |
| Queste diapositive | |
| https://thirstyhead.com/groceryworks | |
| GroceryWorks: un sito web surreale per acquistare alimenti online | |
| https://github.com/thirstyhead/groceryworks | |
| Codice di GroceryWorks | |
| https://github.com/thirstyhead/groceryworks-test | |
| Codice di Gauge e Taiko User Journey test per GroceryWorks | |
Di seguito i collegamenti a queste diapositive a il codice di GroceryWorks insieme ai corrispondenti Gauge e Tai ko User Journey tests.
Introduzione a Gauge
Spero che abbiate gradito questa breve introduzione a cosa Gauge e Taiko possono aggiungere nella vostra cassett a degli attrezzi per testare. Grazie per il vostro tempo!
presentato da Scott Davis. Il suo indirizzo email è scott.davis@thoughtworks.com. Il suo Twitter handle è @scottdavis99.