Come testare le tue app Web

Nel settore del software, tutti testano le loro applicazioni in qualche modo. Molti team di sviluppatori hanno schemi di test elaborati che sono ben integrati con le loro pipeline di integrazione continua, ma anche coloro che non hanno test automatici devono ancora trovare modi per verificare che il loro codice funzioni come previsto.

Costruire un sito web e cliccarlo manualmente con l’aiuto di un browser è una varietà di test. Anche se non è il più sofisticato, conta ancora. Lo stesso vale per l’attivazione di cURL nella console e l’invio di una richiesta sintetica all’endpoint API appena creato.

Questo post discuterà come automatizzare i test manuali che già facciamo prima di tuffarsi in diversi tipi di test e metodologie.

Automatizzare i test

I test manuali sono sufficienti per le app di piccole dimensioni, ma, quando queste app crescono, la loro superficie testabile cresce con esse, causando due problemi.

Uno, quando le persone devono eseguire test ogni volta che una nuova versione di un’app è terminata, possono sorgere incongruenze. Questo è particolarmente vero se ci sono molti test. Due, la persona che esegue i test non può eseguire altre attività. Con le app di grandi dimensioni, il test potrebbe richiedere più giorni.

Il modo più logico per risolvere questi due problemi è automatizzare queste attività manuali. Esistono due tipi principali di test per le app Web: test dell’interfaccia utente e test API. Due strumenti possono automatizzarli.

Test UI

I test UI possono essere eseguiti con uno strumento chiamato Puppeteer. Puppeteer consente di automatizzare un test dell’interfaccia utente manuale utilizzando JavaScript. Viene installato tramite NPM con il seguente comando:

 $ npm i puppeteer

È quindi possibile scrivere uno script che controlla una versione senza testa di Chrome per eseguire i test. Questo script potrebbe essere simile al seguente:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

In questo script, stiamo iniziando un’istanza senza testa di Chrome, navigando verso example.com, e cercando un elemento h1. Se non esiste, viene registrato un messaggio di errore.

Test API

I test API possono essere automatizzati tramite Postino. Postman è dotato di un’interfaccia grafica per la creazione di richieste HTTP che possono essere salvate. Queste richieste possono essere eseguite in seguito con un semplice clic del mouse.

Per iniziare, scaricare e installare l’interfaccia utente Postman. Sono necessari i seguenti passaggi per creare e salvare una richiesta:

1. fare Clic su Crea una Collezione sulla sinistra
2. Entrare nella Mia Collezione, come il nome della collezione
3. fare Clic su Crea
4. fare Clic sui puntini di sospensione (…) della Mia Collezione sulla sinistra
5. Selezionare Aggiungi Richiesta
6. Invio la Mia Richiesta in quanto la richiesta di nome
7. fare Clic su Salva per la Mia Collezione

La richiesta mostra nella barra laterale sinistra sotto il vostro nuovo collezione.

Se lo selezioni, dovrai inserire example.com come URL e aggiungere un test. Per aggiungere un test, fare clic su Test nella barra delle schede sotto il campo di immissione URL.

Apparirà un’area di testo in cui è possibile scrivere il test in JavaScript. Di seguito è riportato un esempio di test:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

Se fai clic su Salva nell’angolo in alto a destra dello schermo e Invia subito dopo, la tua richiesta verrà inviata. Lo script di test verrà quindi eseguito per determinare se la risposta ha stato 200 o meno.

Tipi di test

Esistono tre diversi tipi di test. La loro comprensione consente di scegliere il giusto tipo di test per le varie parti dello stack software.

Unit Test

Unit test sono il tipo più semplice di test. Controllano la correttezza di piccole parti del tuo codice. Un test unitario di solito copre una chiamata a una funzione o un modo per utilizzare una classe.

Un test unitario è solitamente il primo “utente” del codice. Alcune metodologie di test richiedono anche di scrivere il test prima dell’implementazione del codice dell’applicazione reale.

I test unitari possono essere utilizzati sia nello sviluppo di back-end che di front-end. Alcuni team di sviluppo utilizzano unit test per controllare l’output DOM renderizzato di piccole parti del loro codice, come moduli o menu. Nel backend, i test unitari vengono spesso utilizzati per testare il codice tra il server HTTP e il database o altre API.

Tre corridori di test ampiamente utilizzati per i test unitari sono:

‐ Jest—Jest è utilizzato principalmente nello sviluppo di frontend perché è dotato di caratteristiche uniche, come il test di snapshot, che aiutano con problemi come le regressioni dell’interfaccia utente. Un tutorial scherzo può essere trovato qui.

‐ AVA-AVA è favorita nello sviluppo di back-end perché è specializzata nell’esecuzione altamente parallela di test. Un tutorial AVA può essere trovato qui.

‐ PHPUnit—PHPUnit è un framework popolare per unit test in PHP. Un tutorial PHPUnit può essere trovato qui.

Se un test unitario richiede alcune risorse esterne, come connessioni di rete o database, probabilmente stai scrivendo un test di integrazione. Questo tipo di test è coperto successivo.

Test di integrazione

Dal punto di vista dell’implementazione, i test di integrazione sembrano test unitari. La differenza è che i test di integrazione testano più parti dello stack insieme. Ad esempio, potrebbero verificare se il client e il server parlano lo stesso protocollo o, in un’architettura di microservizi, se i servizi funzionano correttamente insieme.

I controlli che di solito finirebbero in più test unitari indipendenti possono essere aggregati in un test di integrazione che determina se tutto funziona bene insieme.

I test di integrazione vengono utilizzati sia nello sviluppo di frontend che di backend. A volte vengono utilizzati per vedere se le due parti interagiscono correttamente, ma possono anche essere utilizzati per determinare se diversi moduli di una parte stanno lavorando insieme come previsto.

È possibile utilizzare gli stessi corridori di prova per i test di integrazione utilizzati per i test unitari. Tuttavia, Postman, lo strumento UI utilizzato sopra per automatizzare i test API manuali, viene fornito con uno strumento CLI chiamato Newman che può essere integrato con la pipeline CI/CD.

Newman può eseguire raccolte Postman esportate, consentendo di creare richieste e test con l’interfaccia utente Postman ed eseguirli successivamente tramite CLI. Un tutorial di Newman può essere trovato qui.

Se un test di integrazione richiede l’interazione con l’interfaccia utente, viene chiamato test dell’interfaccia utente—indirizzato successivamente.

UI Test

UI test sono i test più sofisticati. Cercano di emulare il comportamento dell’utente in modo automatico in modo che i tester non debbano fare clic manualmente su ogni parte della loro app.

I test dell’interfaccia utente spesso aiutano a catturare un’interazione specifica che ha portato a un errore per un utente. Una volta catturato, può essere riprodotto con un clic per correggere il bug e impedirgli di tornare in una nuova versione.

I corridori Jest e AVA test menzionati prima possono essere utilizzati qui, ma di solito è necessaria una libreria aggiuntiva per facilitare l’interazione dell’interfaccia utente tramite un browser. Le due librerie principali attualmente in uso per questo processo sono:

‐ Selenium—Selenium è un framework che consente il controllo remoto di un browser tramite una libreria chiamata WebDriver. Un tutorial sul selenio può essere trovato qui.

Esistono più tipi di test rispetto a quelli elencati qui. Altri possono avere obiettivi diversi; ad esempio, i test di carico cercano di trovare i colli di bottiglia delle prestazioni. Tieni presente che ai test descritti qui a volte vengono dati nomi diversi. I tre tipi presentati sopra sono quelli essenziali da implementare quando si inizia. Utilizzare uno di questi è meglio che non utilizzare alcun test automatico.

Metodologie di test

Le metodologie di test sono modi per pensare ai test. I tre descritti di seguito sono quelli più comunemente usati.

Test Driven Development (TDD)

TDD è la metodologia più utilizzata e la più tecnica. Si consiglia di scrivere i test prima di scrivere il codice effettivo che si desidera testare. Dal momento che devi scrivere un test solo per la parte del codice che stai implementando, il tipo di test che scriverai è un test unitario.

I test unitari sono piuttosto granulari, quindi, nel tempo, l’uso di questa metodologia comporta l’accumulo di molti test. Questa realtà, in coppia con il fatto che i praticanti principianti TDD tendono a scrivere test banali, può portare alla creazione di una pila di test inutili. Per evitare ciò, è fondamentale aggiornare e ripulire i test quando il team ha acquisito maggiore familiarità con TDD e con i test in generale.

È importante eseguire i test frequentemente, non solo in una pipeline CI/CD, ma anche localmente sulla macchina di sviluppo. Scrivere un test, eseguirlo, vederlo fallire, implementare abbastanza per far passare il test e ripetere il processo.

Per ulteriori letture, controlla la descrizione di TDD di Agile Alliance.

Acceptance Test Driven Development (ATDD)

ATDD è una modifica di TDD che si concentra più sui casi aziendali e meno sull’implementazione tecnica. I tipi di test utilizzati in questa metodologia sono per lo più test di integrazione, perché, spesso, più parti del sistema devono essere utilizzate insieme per risolvere un’esigenza aziendale.

Poiché i test sono meno tecnici, è anche consigliabile includere persone non tecnicamente orientate nel processo di test. I proprietari di prodotti e i clienti possono aiutare a definire i casi aziendali in modo che uno sviluppatore possa scrivere un test per loro. Se il test non può essere eseguito correttamente, è chiaro che è necessario implementare più funzionalità.

ATDD lavora su un livello di astrazione diverso da TDD, quindi le due metodologie possono essere utilizzate insieme.

Per ulteriori letture, controlla la descrizione di TDD di Agile Alliance.

Behavior Driven Development (BDD)

BDD è un mix di TDD e ATDD, e il suo obiettivo è quello di utilizzare il meglio di entrambi i mondi per rendere il sistema complessivo più stabile. BDD tenta di specificare un sistema con test che illustrano il suo utilizzo.

Come ATDD, BDD tenta di catturare casi aziendali. Tuttavia, richiede anche di mettere in discussione questi casi d’uso con “5 whys” perché i “whys” sono una parte mancante in ATDD. Certo, è meglio chiedere ai clienti cosa vogliono invece di affidarsi esclusivamente all’input dello sviluppatore. Ma è anche importante mettere in discussione le ipotesi di entrambi questi gruppi.

BDD è anche un mix di TDD e ATDD nel senso dei livelli di astrazione. TDD verifica solo le piccole parti dell’applicazione e ATDD verifica solo il modo in cui queste parti funzionano insieme. BDD richiede di applicare questa metodologia al grande insieme della tua app e alle sue piccole parti, rendendo BDD un approccio più olistico ai test.

Per ulteriori letture, controlla la descrizione di BDD di Agile Alliance.

Conclusione

Mentre nessun test è terribile, il test manuale è migliore e il test automatizzato è il migliore.

A seconda delle dimensioni della tua app, un test manuale può impedire ai membri del team di sviluppo di lavorare su altri progetti per giorni o addirittura settimane, costando tempo e denaro alla tua attività. Inoltre, il compito monotono di eseguire le stesse interazioni più e più volte può portare a scivoloni che spesso si manifestano in bug non rilevati.

I computer sono molto bravi a ripetere lo stesso compito più e più volte, quindi è una buona idea delegare il test a uno script e liberare il tempo dei tuoi sviluppatori. Se questi test sono integrati nella pipeline CI/CD, i test già scritti possono essere eseguiti implicitamente quando un nuovo commit atterra nei repository.

È una buona idea impiegare una metodologia di test nella fase iniziale, perché, spesso, i grandi problemi quando si inizia sono “cosa” e “quando” testare. Queste metodologie possono aiutare a chiarire un processo che rende i test di scrittura più coerenti per tutti i membri del team.