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.
use Tester\Assert;
class RectangleTest extends Tester\TestCase
{
public function testOne()
{
Assert::same(/* ... */);
}
public function testTwo()
{
Assert::match(/* ... */);
}
}
# Run testing methods
(new RectangleTest)->run();
Possiamo arricchire un testcase con i metodi setUp()
e tearDown()
. Essi vengono chiamati prima/dopo
ogni metodo di test:
use Tester\Assert;
class NextTest extends Tester\TestCase
{
public function setUp()
{
# Preparation
}
public function tearDown()
{
# Clean-up
}
public function testOne()
{
Assert::same(/* ... */);
}
public function testTwo()
{
Assert::match(/* ... */);
}
}
# Run testing methods
(new NextTest)->run();
/*
Method Calls Order
------------------
setUp()
testOne()
tearDown()
setUp()
testTwo()
tearDown()
*/
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.
<?php
/** @testCase */
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:
/**
* @throws RuntimeException
*/
public function testOne()
{
// ...
}
/**
* @throws LogicException Ordine degli argomenti errato
*/
public function testTwo()
{
// ...
}
@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:
public function getLoopArgs()
{
return [
[1, 2, 3],
[4, 5, 6],
[7, 8, 9],
];
}
/**
* @dataProvider getLoopArgs
*/
public function testLoop($a, $b, $c)
{
// ...
}
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
:
[one]
a=1
b=2
c=3
[two]
a=4
b=5
c=6
[three]
a=7
b=8
c=9
e il metodo che utilizza il file INI:
/**
* @dataProvider loop-args.ini
*/
public function testLoop($a, $b, $c)
{
// ...
}
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
:
return [
['a' => 1, 'b' => 2, 'c' => 3],
['a' => 4, 'b' => 5, 'c' => 6],
['a' => 7, 'b' => 8, 'c' => 9],
];