Lo Unit Test 竪 importante per testare gli aspetti di base di un qualsiasi applicativo PHP.
Con il framework PHPUnit noi possiamo effettuare test di unit senza problemi e senza notevoli sforzi.
5. Introduzione a PHPUnit
PHPUnit 竪 un framework scritto da Sebastian Bergmann
per lo Unit testing in PHP.
Lobiettivo 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.
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 limpatto 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
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.
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.
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 lAPI, 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.
26. Testare le API
Questo test 竪 fragile perch竪 si affida al fatto che lAPI sia
disponibile nellesatto momento in cui il test viene eseguito.
Cosa succede se lAPI 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 lAPI torna quello che ci aspettiamo. Controllate
periodicamente se lAPI che state utilizzando continui a
ritornare ci嘆 che si si aspetta o si finir con dei test che non
rispettano la realt.
28. Testare le API
Wrapper API livello di astrazione in pi湛
Creiamo un oggetto wrapper che prende la risposta
dalloggetto 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.
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.
35. Testare le Eccezioni
PHPUnit 竪 in grado di verificare leccezione con il
corrispondente messaggio utilizzato nelle due annotazioni.
@expectedException 竪 configurato per essere leccezione
che vi aspettate mentre @expectedExceptionMessagesar
il messaggio che ci aspettiamo generato dalla eccezione.
C竪 una terza annotazione che potete usare,
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 leccezione, rende pi湛
semplice il debug del test se fallisce.