Como já mencionei em um artigo anterior, o PHPUnit é um framework de testes unitários para a linguagem PHP. Ele provê um ecossistema para a execução de testes de forma automatizada.
Neste artigo veremos a sua instalação utilizando o gerenciador de pacotes composer, configuração e estrutura de pastas e alguns testes simples sem persistência de dados.
Instalando o PHPUnit
Para iniciar a instalação do PHPUnit precisamos primeiramente de um diretório que será nosso diretório de trabalho neste exemplo. Após criado o diretório é necessário criar um arquivo chamado composer.json para que seja definida a necessidade do PHP Unit no projeto. O arquivo composer_.json_ é responsável por declarar todas as bibliotecas que serão necessárias para o projeto em questão, em suma todas soluções de terceiros, incluindo suas soluções genéricas que encontrem-se no repositório do composer serão gerenciadas conforme a especificação do arquivo composer.json.
O arquivo para este artigo deverá conter o seguinte conteúdo:
Isto quer dizer que estamos registrando como uma dependência de nosso projeto o PHPUnit em sua versão 3.7 sempre solicitando a última atualização. Para que sempre seja utilizada a última versão do PHPUnit basta remover a sequência “3.7.*” por simplesmente “*”. O mesmo é possível com qualquer biblioteca gerenciada pelo composer.
Agora já estão prontas as declarações de nossas dependências basta baixar o gerenciador de dependência composer e rodar o comando
Isto irá de maneira automática baixar todas as dependências que foram especificadas no arquivo composer.json, e neste exemplo trata-se apenas do PHPUnit no entanto o próprio PHP Unit requer algumas bibliotecas de terceiros então outras bibliotecas estarão disponíveis além do mesmo dentro da pasta vendor que será criada.
Existe uma convenção de padrões definidos pela FIG chamada PSR (Proposal Standards Recommendation). Para facilitar será utilizada a definição do Autoloader para o exemplo que está descrito na PSR-0. Após a correta instalação via composer devem ser criadas os diretórios src e dentro dele Application.
Com a definição do Autoloader a nova estrutura do composer é a seguinte:
No arquivo composer.json agora é dito que o autoloader deve reconhecer o namespace “Application” que encontra-se dentro do diretorio src.
Como o PHPUnit já está instalado corretamente no projeto agora vem a parte legal que é criar pequenos testes (unitários, obviamente) e colocar em prática o vermelho-verde-refatora já mencionado no meu post anterior TDD, por que usar?.
Primeiramente deve ser criada a pasta tests que servirá para acomodar todos os casos de teste a serem executados.
Começando com um teste simples, e na verdade este artigo somente mostrará o uso simplificado pois a finalidade do mesmo é apenas mostrar o caminho das pedras, como começar, instalar, configurar e rodar os primeiros testes. A partir daí cabe à necessidade de cada desenvolvedor.
Aqui será criado um arquivo PHPNativeElements onde serão testados algumas funções nativas do PHP e seus comportamentos. Obviamente que este caso de teste calha somente em modo didático pois tais testes e classe testada terá muito mais de uma única responsabilidade, é somente em caráter demonstrativo.
Criado o arquivo PHPNativeElementsTest.php dentro do diretório tests, siga o exemplo abaixo.
Para que seja reconhecido como um teste o arquivo deve conter a sufixo Test.
Executando de forma simples
Como o PHPUnit foi instalado a partir do composer, é a partir da estrutura montada pelo mesmo que este será executado digitando no terminal
Com isto uma tela de ajuda deve aparecer com todas as opções disponíveis para a utilização do PHPUnit. Seguem as definições do comando que será executado neste primeiro momento.
./vendor/bin/phpunit –colors –debug tests/PHPNativeElements onde:
./vendor/bin/phpunit: o próprio executável do PHPUnit
–colors: habilita coloração ( assim podemos ver os estágios vermelho-verde de forma mais simples)
–debug: habilita o modo debug para detalhamento das ações que estão sendo tomadas durante os testes – Esta ação serve como ótima documentação como já mencionado em meu artigo anterior.
tests/PHPNativeElements: o nome da classe de testes a ser testada.
Ao rodarmos o comando acima a mensagem resultante deverá ser a de que não há testes disponíveis na classe testada.
Fazendo o primeiro teste passar
Após o método tearDown que já encontra-se na classe PHPNativeElementsTest crie um método chamado testOperacaoMatematica. Assim como a classe de teste possui uma convenção com os métodos também é necessário especificar qual trata-se de um teste a partir do prefixo test. Por este motivo nosso primeiro caso de teste se chamar testOperacaoMatematica. Caso não contenha o prefixo test e, não sendo os métodos setUp e tearDown, o PHPUnit simplesmente não executa o método.
Como estamos utilizando o Autoloader, em nossa classe de teste usaremos o namespace “_Application_NativeElementsMath” para carregar a nossa classe que será testada a partir da classe de testes. Como atributo de nossa classe de teste adicionaremos “$math” e nele instanciaremos a classe _Application_NativeElementsMath dentro do método setUp.
_Application_NativeElementsMath ainda não existe. Este é o próximo passo, o código que fará o testes passar.
Math.php dentro do diretório Application/NativeElements e no mesmo a classe Math definindo como namespace ApplicationNativeElements. Por hora nenhum método é criado nesta nova classe.
sum ).
Como pode ser percebido, como terceiro parâmetro do assert foi adicionada uma mensagem opcional, isso para que ao dar erro da asserção tal mensagem seja exibida, conforme a imagem seguinte.
Refatorando
Math, dá pra perceber que há muita repetição pois todos os métodos recebem dois valores e retornam uma operação correspondente. Como utilizando TDD temos segurança em desenvolver, podemos tranquilamente remover tais repetições criando uma interface onde é previamente definida a operação a ser realizada e retorna o resultado desta operação. Obviamente com esta atitude o teste também sofrerá alterações e isso é algo comum pois uma aplicação está sempre evoluindo.
Frenta à necessidade de refatoração novamente começamos a partir do teste e ele fica como na imagem a seguir:
Este é apenas um exemplo didático de refatoração, mas mesmo com ele dá pra perceber como houve a anulação de código repetido e para um futura manutenção basta que mexa-se em um local somente para que surta efeitos à todas as operações matemáticas.
Finalizando
link e é o primeiro artigo da sequência.
- Configurações avançadas – Apenas uma breve abordagem de como realizar configurações avançadas na execução do PHPUnit gerando reports como coverage.
- Persistência – Será utilizado o ORM Doctrine para complementarmos o projeto
- Mockery – Utilizando objetos simulados para atender certos comportamentos
Você pode baixar o código-fonte dos exemplos apresentados aqui no github.
