Il documento offre una panoramica sul framework PHPUnit, progettato per facilitare il unit testing in PHP. Vengono descritti concetti chiave come test case, test double, data providers, e metodologie per testare API e database, oltre a strategie per gestire le eccezioni. Infine, sottolinea l'importanza di utilizzare dati realistici durante i test per garantire risultati significativi.

1. PHPUnit
Pietro Alberto Rossi

2. Chi sono
Android Developer per
Hobby
Speaker per Hobby
Kebab-man
Pizza-man
Rompiscatole
Logorroico
Litigato con le lingue
estere

3. Agenda
Introduzione a PHPUnit
Test Double
Data Provider
Creare Test Data
Testare le API
Testare Database
Testare le Eccezioni

4. Perché Test?

5. Introduzione a PHPUnit
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.

6. Introduzione a PHPUnit
Si può installare tramite Pear o tramite Composer.

7. Introduzione a PHPUnit
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.

8. Introduzione a PHPUnit
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.

9. Introduzione a PHPUnit
 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

10. Introduzione a PHPUnit
 Si può avviare direttamente una test suite

11. Test Double
 Dummy Object
 Test Stub
 Test Spy
 Test Mock
 Test Fake

12. Dummy Object
Oggetto di cui non ci importa cosa faccia perché non parte del
test.

13. Dummy Object
Oggetto di cui non ci importa cosa faccia perché non parte del
test.

14. Test Stub
Oggetto che modifichiamo per avere una specifica risposta.

15. Test Spy
Oggetto che si preoccupa soltanto che il metodo che si sta
verificando venga eseguito un certo numero di volte.

16. 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.

17. Data Provider
Esempio data provider

18. Data Provider
Singola funzione di test invece di una funzione per valore

19. Data Provider
Database, CSV o vari formati di dati…

20. 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.

21. Creare Test Data
Serializzazione e memorizzazione.

22. 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.

23. 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.

24. Testare le API
Esempio

25. Testare le API
Cosa c’è di errato?

26. 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à.

27. Testare le API
Come dovremmo fare?

28. 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.

29. 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.

30. Testare le API

31. 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.

32. 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.

33. Testare Database

34. Testare Database

35. Testare le Eccezioni
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,

36. Testare le Eccezioni

37. Testare le Eccezioni
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.

38. Testare le Eccezioni

39. Testare le Eccezioni
Potete sempre intercettare l’eccezione tramite il blocco try-catch
nel test stesso.

40. <Grazie!>
pietroalberto.rossi@gmail.com
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