Nette Documentation Preview

syntax
Caso di prova
*************

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

```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();
```

Possiamo arricchire un testcase con i metodi `setUp()` e `tearDown()`. Essi vengono chiamati prima/dopo ogni metodo di 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()
*/
```

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


Annotazione dei metodi .[#toc-annotation-of-methods]
====================================================

Sono disponibili alcune annotazioni per aiutarci a testare i metodi. Le scriviamo verso il metodo di test.


@girate .[filter]
-----------------
È un uso uguale di `Assert::exception()` all'interno di un metodo di test. Ma la notazione è più leggibile:

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


/**
 * @throws LogicException Ordine degli argomenti errato
 */
public function testTwo()
{
	// ...
}
```


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

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:

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

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

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

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

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],
];