Caso di prova
Le asserzioni possono seguire una per una nei test semplici. Ma a volte è utile racchiudere le asserzioni in una classe di test e strutturarle in questo modo.
La classe deve essere discendente di Tester\TestCase
e se ne parla semplicemente come di testcase.
Possiamo arricchire un testcase con i metodi setUp()
e tearDown()
. Essi vengono chiamati prima/dopo
ogni metodo di test:
Se si verifica un errore in una fase di setUp()
o tearDown()
, il test fallisce. Se si verifica un
errore nel metodo di test, il metodo tearDown()
viene chiamato comunque, ma con gli errori soppressi.
Si consiglia di scrivere l'annotazione @testCase all'inizio del test, in modo che il test runner a riga di comando esegua i singoli metodi del testcase in processi separati e in parallelo in più thread. Questo può accelerare notevolmente l'intero processo di test.
Annotazione dei metodi
Sono disponibili alcune annotazioni per aiutarci a testare i metodi. Le scriviamo verso il metodo di test.
@girate
È un uso uguale di Assert::exception()
all'interno di un metodo di test. Ma la notazione è più leggibile:
@dataProvider
Questa annotazione è adatta quando si vuole eseguire il metodo di test più volte, ma con argomenti diversi. (Da non confondere con l'annotazione omonima per i file).
Come argomento si scrive il nome del metodo che restituisce i parametri per il metodo di test. Il metodo deve restituire un array o un Traversable. Esempio semplice:
L'altra variazione dell'annotazione @dataProvider accetta come argomento un percorso del file INI (relativamente al file
di prova). Il metodo viene richiamato un numero di volte pari al numero di sezioni contenute nel file INI. File
loop-args.ini
:
e il metodo che utilizza il file INI:
Allo stesso modo, si può passare il percorso a uno script PHP invece di INI. Deve restituire un array o un Traversable. File
loop-args.php
: