Até agora, temos apenas dois testes para Array e a função integrada sizeof(). Quando começamos a testar um grande número de funções array_*(), precisamos de um teste para cada uma. Podemos escrever cada um do zero. No entanto, uma abordagem melhor é escrever a infraestrutura de teste uma vez e depois escrever apenas as diferentes partes de cada teste. PHPUnit é uma dessas infraestruturas.
O Exemplo 5 mostra como reescrever os dois testes do Exemplo 4 usando PHPUnit.
Exemplo 5. Teste Array e sizeof() com PHPUnit
.
require_once 'PHPUnit2/Framework/TestCase.php';
classe ArrayTest estende PHPUnit2_Framework_TestCase {
função pública testNewArrayIsEmpty() {
//Cria array de fixture.
$fixação = Array();
// Afirma que o tamanho do array fixture é 0.
$this->assertEquals(0, sizeof($fixture));
}
função pública testArrayContainsAnElement() {
//Cria array de fixture.
$fixture = Array()
// Adiciona um membro ao array fixture.
$fixture[] = 'Elemento';
//Afirma que o tamanho do array fixture é 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
O exemplo 5 nos diz que os passos básicos para usar o PHPUnit para escrever testes são:
1. A classe de teste para a classe Class é ClassTest.
2. ClassTest geralmente herda PHPUnit2_ Framework_TestCase.
3. Test é um método público sem parâmetros e seu nome é test*.
4. No método de teste, funções de asserção como assertEquals() (consulte a Tabela 6) são usadas para afirmar se o valor real corresponde ao valor esperado.
Um framework como o PHPUnit precisa resolver uma série de problemas, alguns dos quais parecem conflitantes entre si. Os testes também devem atender às seguintes condições:
Fácil de aprender
Os testes devem ser fáceis de aprender, caso contrário, os desenvolvedores não aprenderão
Fácil de desenvolver
Os testes devem ser fáceis de desenvolver, caso contrário, os desenvolvedores não desenvolverão
Fácil de ler
O código de teste não deve ter relacionamentos externos , para que o teste em si não se perca na confusão.
Fácil de executar
Os testes devem ser fáceis de executar e os resultados da execução devem ser expressos num formato claro e inequívoco.
Execução Rápida
Os testes devem ser executados rapidamente para que possam ser executados milhares de vezes por dia.
Os testesde isolamento de código
não podem afetar uns aos outros e as alterações na ordem dos testes não devem afetar os resultados.
Composable
Devemos ser capazes de executar testes em qualquer combinação, o que é um corolário do isolamento de código.
Existem dois conflitos principais entre essas restrições:
Facilidade de Aprendizagem versus Facilidade de Desenvolvimento
Os testes geralmente não exigem flexibilidade total de programação. Muitas ferramentas de teste fornecem suas próprias linguagens de script de teste. Essas linguagens possuem apenas o conjunto mínimo de recursos necessários para escrever testes. Como não há ruído que interfira no conteúdo do teste, os testes escritos são fáceis de ler e escrever. Mas aprender uma nova mala direta de tricô e um conjunto de ferramentas ainda é inconveniente e facilmente confuso.
Isolamento de código versus execução rápida
Se quiser que os resultados de um teste não afetem outro, será necessário criar um tópico completo para o teste no início de cada teste e, em seguida, restaurar o estado antes da execução. No entanto, configurar o estado leva muito tempo (por exemplo, conectar-se ao banco de dados e inicializar para um estado conhecido com dados reais.
A solução do PHPUnit para esse problema é usar PHP como linguagem de teste). Às vezes, o PHP completo é poderoso demais para escrever testes curtos e diretos, mas os programadores que usamos já têm experiência completa com PHP. Como precisamos convencer os testadores relutantes, é extremamente importante diminuir a barreira para escrever esses testes iniciais.