TestCase
********

.[perex]
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**.

```php
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 :

```php
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 |test-annotations#@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
<?php
/** @testCase */
\--


Annotation des méthodes .[#toc-annotation-of-methods]
=====================================================

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


@throws .[filter]
-----------------
C'est la même utilisation de `Assert::exception()` dans une méthode de test. Mais la notation est plus lisible :

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


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


@dataProvider .[filter]
-----------------------
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 |test-annotations#dataProvider]).

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 :

```php
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`:

```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 :

```php
/**
 * @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`:

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