TestCase

Les assertions peuvent se suivre une par une dans les tests simples. Mais parfois il est utile d'enfermer les assertions dans une classe de test et de les structurer de cette façon.

La classe doit être un descendant de Tester\TestCase et nous en parlons simplement comme de 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();

Nous pouvons enrichir un testcase par les méthodes setUp() et tearDown(). Elles sont appelées avant/après chaque méthode de 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()
*/

Si une erreur se produit dans une phase de setUp() ou tearDown(), le test échouera. Si une erreur se produit dans la méthode de test, la méthode tearDown() est quand même appelée, mais avec des erreurs supprimées.

Nous vous recommandons d'écrire l'annotation @testCase au début du test. Le gestionnaire de test en ligne de commande exécutera alors les différentes méthodes de test dans des processus séparés et en parallèle dans plusieurs threads. Cela peut accélérer considérablement l'ensemble du processus de test.

<?php
/** @testCase */

Annotation des méthodes

Il existe quelques annotations pour nous aider à tester les méthodes. Nous les écrivons vers la méthode de test.

@throws

C'est la même utilisation de Assert::exception() dans une méthode de test. Mais la notation est plus lisible :

/**
 * @throws RuntimeException
 */
public function testOne()
{
	// ...
}


/**
 * @throws LogicException Mauvais ordre des arguments
 */
public function testTwo()
{
	// ...
}

@dataProvider

Cette annotation convient lorsque nous voulons exécuter la méthode de test plusieurs fois mais avec des arguments différents. (A ne pas confondre avec l'annotation du même nom pour les fichiers).

Comme argument, nous écrivons le nom de la méthode qui renvoie les paramètres de la méthode de test. La méthode doit retourner un tableau ou un Traversable. Exemple simple :

public function getLoopArgs()
{
	return [
		[1, 2, 3],
		[4, 5, 6],
		[7, 8, 9],
	];
}


/**
 * @dataProvider getLoopArgs
 */
public function testLoop($a, $b, $c)
{
	// ...
}

L'autre variation de l'annotation @dataProvider accepte un chemin vers le fichier INI (relativement au fichier de test) comme argument. La méthode est appelée autant de fois que le nombre de sections contenues dans le fichier INI. Fichier loop-args.ini:

[one]
a=1
b=2
c=3

[two]
a=4
b=5
c=6

[three]
a=7
b=8
c=9

et la méthode qui utilise le fichier INI :

/**
 * @dataProvider loop-args.ini
 */
public function testLoop($a, $b, $c)
{
	// ...
}

De même, nous pouvons passer le chemin d'accès à un script PHP au lieu de l'INI. Il doit retourner un tableau ou un Traversable. Fichier loop-args.php:

return [
	['a' => 1, 'b' => 2, 'c' => 3],
	['a' => 4, 'b' => 5, 'c' => 6],
	['a' => 7, 'b' => 8, 'c' => 9],
];