phpunit

PHPUnitPietro Alberto Rossi

Chi sono

Android Developer per

Hobby

Speaker per Hobby

Kebab-man

Pizza-man

Rompiscatole

Logorroico

Litigato con le lingue

estere

Agenda

Introduzione a PHPUnit

Test Double

Data Provider

Creare Test Data

Testare le API

Testare Database

Testare le Eccezioni

Perché Test?


PHPUnit è un framework scritto da Sebastian Bergmann

per lo Unit testing in PHP.

L’obiettivo principale è facilitare la scrittura di test ed il loro

riutilizzo, in modo che il programmatore non debba perdere

troppo tempo in tutte quelle operazioni di contorno che

potrebbero rendere tedioso il lavoro ed allontanare alcune

persone da questa pratica.


Si può installare tramite Pear o tramite Composer.


Questo è quello che voglio chiamare “Minimum Viable Test

class”. Tutte le classi devono ereditare dalla classe

PHPUnit_Framework_TestCase, anche se è più usuale che

le persone creino la propria classe base da cui

estenderanno tutte le altre classi per effettuare i loro test.


I test case sono un insieme di condizioni o variabili sotto le

quali un tester determina se una applicazione o sistema

software risponde correttamente o meno.

I test suite sono dei modi per raggruppare i test. Questo

può essere utile se state effettuando dei cambiamenti in

molto codice e volete solamente eseguire i test per

verificare l’impatto con i cambiamenti.


Tutti i tipi di asserzioni che PHPUnit possiede, seguono

lo stesso pattern:

• tipo di asserzione • valore aspettato • valore generato

dal test • messaggio opzionale se il test fallisce


Si può avviare direttamente una test suite

Test Double

Dummy Object

Test Stub

Test Spy

Test Mock

Test Fake

Dummy Object

Oggetto di cui non ci importa cosa faccia perché non parte del

test.

Test Stub

Oggetto che modifichiamo per avere una specifica risposta.

Test Spy

Oggetto che si preoccupa soltanto che il metodo che si sta

verificando venga eseguito un certo numero di volte.

Data Provider

Uno dei principali obiettivi che ci dovrebbe sempre essere è

scrivere il minor codice possibile per risolvere un

determinato problema. Questo non è differente quando si

tratta di test, che sono veramente nulla di più che codice.

Un data provider è un modo per creare set multipli di dati

da testare che possono essere passati ad un test method

come parametro. Voi create un metodo che è disponibile

nella classe ed il tuo test ritornerà un array di valori che

coincideranno con i parametri che state passando al test.

Data Provider

Esempio data provider

Data Provider

Singola funzione di test invece di una funzione per valore

Data Provider

Database, CSV o vari formati di dati…

Creare Test Data

Se state testando funzionalità che hanno bisogno di dati da

manipolare, avete bisogno di capire come creare e fornire

dati reali per i vostri test.

Da notare che la parola chiave è “reali”. Anche i migliori test

non sono di alcuna utilità se utilizzano dati che sono molto

diversi dai dati utilizzati in produzione.

Creare Test Data

Serializzazione e memorizzazione.

Creare Test Data

Ricordate, in precedenza, che ho sottolineato che la

condizione ottimale è avere dati realistici? Quando scrivete

test è allettante darci un taglio.

Faker è un buon tool per generare dati random come nomi,

indirizzi e numeri di telefono.

Testare le API

Testare le chiamate API non è differente dal testare

qualsiasi altro tipo di codice: vi aspettate un output,

eseguite del codice che chiama l’API, verificate che il test

ritorni il valore che vi aspettate.

Il test più comune che le persone cercano di fare è quello di

prendere dei dati da una API e successivamente

trasformarli in qualche modo.

Testare le API

Esempio

Testare le API

Cosa c’è di errato?

Testare le API

Questo test è fragile perchè si affida al fatto che l’API sia

disponibile nell’esatto momento in cui il test viene eseguito.

Cosa succede se l’API non è disponibile durante il test?

Questo potrebbe essere limitante se avete problemi di

banda.

Utilizzando direttamente le API comporta di essere sicuri al

100% che l’API torna quello che ci aspettiamo. Controllate

periodicamente se l’API che state utilizzando continui a

ritornare ciò che si si aspetta o si finirà con dei test che non

rispettano la realtà.

Testare le API

Come dovremmo fare?

Testare le API

Wrapper API livello di astrazione in più

Creiamo un oggetto wrapper che prende la risposta

dall’oggetto API e poi applichiamo le nostre trasformazioni.

In questo modo, il wrapper non ha bisogno di sapere che

non sta trattando una situazione reale. Sa solamente che

prende qualcosa e che sa come usarla.

Testare le API

Mock API

Proprio come qualsiasi altro test, seguiamo la stessa

logica: creiamo uno scenario, creiamo oggetti mock

richiesti dallo scenario, e successivamente testiamo il

nostro codice per essere sicuri che, basato sul nostro set di

input, abbiamo la risposta che ci aspettiamo.

Testare le API

Testare Database

Lo svantaggio di scrivere test che parlano direttamente con

il database è che dovete mantenere continuamente un

database di test. Se avete un ambiente di test dove più

sviluppatori condivi- dono lo stesso database, rischiate di

sovrascrittura o addirittura di finire con dati che non hanno

alcuna somiglianza con quelli di produzione.

Testare Database

Ci sono volte quando avete bisogno di parlare con il

database come parte del test, solitamente per verificare se

state salvando delle informazioni sul database.

Testare Database


PHPUnit è in grado di verificare l’eccezione con il

corrispondente messaggio utilizzato nelle due annotazioni.

@expectedException è configurato per essere l’eccezione

che vi aspettate mentre @expectedExceptionMessagesarà

il messaggio che ci aspettiamo generato dalla eccezione.

C’è una terza annotazione che potete usare,


Quando usate le annotazioni, PHPUnit semplicemente si

aspetta che il test vada in eccezione, non curandosi del

punto dove sia accaduta.

Il motivo di utilizzare setExpectedException tramite

annotazioni è che ponendo la chiamata prima del codice

dove ci si aspetta di generare l’eccezione, rende più

semplice il debug del test se fallisce.


Potete sempre intercettare l’eccezione tramite il blocco try-

catch nel test stesso.

<Grazie!>

[email protected]

Sito Web: www.sprik.it

Facebook: facebook.com/sprikmeister

Twitter: @sprik89

Linkedin: it.linkedin.com/in/pietroalbertorossi/

PHPUnit Ricettario del Programmatore Scontroso

https://leanpub.com/phpunitricettariodelprogrammatorescontroso

mailto:[email protected]

phpunit

Engineering