Capítulo 4. Ambientes

setUp() e tearDown() são bastante simétricos em teoria, mas não na prática. Na prática, você só precisa implementar tearDown() se você tiver alocado recursos externos como arquivos ou sockets no setUp(). Se seu setUp() apenas cria objetos planos do PHP, você pode ignorar o tearDown(). de modo geral. Porém, se você criar muitos objetos em seu setUp(), você pode querer remover a configuração unset() você pode querer remover a configuração tearDown() para que eles possam ser coletados como lixo. A coleta de lixo dos objetos dos casos de teste não é previsível.

O que acontece quando você tem dois testes com definições (setups) ligeiramente diferentes? Existem duas possibilidades:

Existem algumas boas razões para compartilhar ambientes entre testes, mas na maioria dos casos a necessidade de compartilhar um ambiente entre testes deriva de um problema de design não resolvido.

Um bom exemplo de um ambiente que faz sentido compartilhar através de vários testes é a conexão ao banco de dados: você loga no banco de dados uma vez e reutiliza essa conexão em vez de criar uma nova conexão para cada teste. Isso faz seus testes serem executados mais rápido.

Exemplo 4.3 usa os métodos-modelo setUpBeforeClass() e tearDownAfterClass() para conectar ao banco de dados antes do primeiro teste da classe de casos de teste e a desconectar do banco de dados após o último teste dos casos de teste, respectivamente.

<?php
class BancoDeDadosTest extends PHPUnit_Framework_TestCase
{
protected static $dbh;

public static function setUpBeforeClass()
{
self::$dbh = new PDO('sqlite::memory:');
}

public static function tearDownAfterClass()
{
self::$dbh = NULL;
}
}
?>

Não dá pra enfatizar o suficiente o quanto o compartilhamento de ambientes entre testes reduz o custo dos testes. O problema de design subjacente é que objetos não são de baixo acoplamento. Você vai conseguir melhores resultados resolvendo o problema de design subjacente e então escrevendo testes usando pontas (veja Capítulo 8), do que criando dependências entre os testes em tempo de execução e ignorando a oportunidade de melhorar seu design.

É difícil testar um código que usa singletons (instâncias únicas de objetos). Isso também vale para os códigos que usam variáveis globais. Tipicamente, o código que você quer testar é fortemente acoplado com uma variável global e você não pode controlar sua criação. Um problema adicional é o fato de que uma mudança de um teste para uma variável global pode quebrar um outro teste.

Em PHP, variáveis globais trabalham desta forma:

Além das variáveis globais, atributos estáticos de classes também são parte do estado global.

Por padrão, o PHPUnit executa seus testes de forma que mudanças às variáveis globais ou super-globais ($GLOBALS, $_ENV, $_POST, $_GET, $_COOKIE, $_SERVER, $_FILES, $_REQUEST) não afetem outros testes. Opcionalmente, este isolamento pode ser estendido a atributos estáticos de classes.

A anotação @backupGlobals que é discutida na seção chamada “@backupGlobals” pode ser usada para controlar as operações de backup e restauração para variáveis globais. Alternativamente, você pode fornecer uma lista-negra de variáveis globais que deverão ser excluídas das operações de backup e restauração como esta:

class MeuTest extends PHPUnit_Framework_TestCase
{
    protected $backupListaNegraGlobais = array('variavelGlobal');

    // ...
}

A anotação @backupStaticAttributes que é discutida na seção chamada “@backupStaticAttributes”pode ser usada para controlar as operações de backup e restauração para atributos estáticos. Alternativamente, você pode fornecer uma lista-negra de atributos estáticos que deverão ser excluídos das operações de backup e restauração como esta:

class MeuTest extends PHPUnit_Framework_TestCase
{
    protected $backupListaNegraAtributosEstaticos = array(
      'nomeClasse' => array('nomeAtributo')
    );

    // ...
}