Escrevendo seu primeiro teste no Laravel 5.4

Olá, DevZ.

Eu já abordei o tema Testes quando escrevi um artigo sobre TDD (Test Driven Development). Se você tem zero conhecimento sobre esse tema, lá é um bom lugar para começar. Nesse artigo eu vou te mostrar na prática como escrever seu primeiro teste no Laravel.

Todo código que não possui cobertura de testes é um código legado.

Essa é, na minha opinião, a melhor definição do que é código legado e por tabela a melhor explicação do porquê você deveria estar escrevendo testes para a sua aplicação.

Mãos na massa. A essa altura você já deve estar acostumado com a interface de linha de comando do Laravel para criar suas migrations e seeds, agora faremos um comando parecido para criamos nosso arquivo de teste.

php artisan make:test ViewTest

Como você pode perceber, nosso exemplo se trata de um teste das views da minha aplicação. O nome é um ponto importante quando falamos sobre testes no Laravel, para que o phpunit encontre nosso arquivo de teste e nossos métodos, eles devem seguir o padrão nomeTest para o arquivo e testNomeDoMétodo para a função dentro do nosso arquivo.

phpunit/phpunit - Packagist

O Laravel providência vários métodos de asserção customizados para você utilizar nos seus testes com o PHPUnit, você pode ver todos eles na documentação. No exemplo acima usamos dois deles: assertStatus e assertViewHas.

Dentro da função que testa a view Point nós fazemos uma requisição get para as rotas onde são criadas os pontos e onde eles são listados, após isso nós dizemos que esperamos que seja recebido um status 200. O que isso significa? Existe uma lista de códigos de resposta HTTP. 200 é a resposta padrão para uma requisição de sucesso.

Outros erros conhecidos são 400 ou 401 para requisições inválidas ou não autorizada. O que estamos fazendo no nosso teste é dizer que esperamos que ao acessar essa rota, ela funcione. Por que isso é útil? Com esse teste, se alguma das minhas controllers não mandar uma variável para a minha view, eu consigo pegar esse erro ao rodar nossos testes e ir direto na view onde estar o problema.

Na linha logo abaixo nós somos mais específicos e com o assertViewHas nós dizemos que aquela rota deve receber aquela variável, ou seja, a variável fornecedor deve estar disponível naquela view. Caso isso não ocorra, o teste irá falhar e nós podemos ir diretamente no foco do nosso problema, tornando muito mais fácil debuggar qualquer erro na sua aplicação.

Esse é só um exemplo simples de como escrever teste pode mudar a sua aplicação e torná-la muito mais sustentável. Para fechar esse artigo nós precisamos rodar os testes e fazemos isso com o seguinte comando.

vendor/bin/phpunit

Após alguns segundos o PHPUnit vai te devolver o resultado dos seus testes apontando quantos testes rodaram, quantas falharam e quantos acertos você teve! Se você gosta de manter o terminal limpo e com pequenos comandos você pode criar um alias para sua ferramenta PHP de testes da seguinte maneira.

sudo nano .bash_profile
alias phpunit=‘$(pwd)/vendor/bin/phpunit’
source ~/.bash_profile

Nós editamos as nossas configurações do Bash utilizando sudo para salvarmos as alterações, dizemos que ao rodar o comando phpunit estamos executando a partir do caminho em que estamos (pwd) aquele comando anterior. Depois de salvarmos o arquivo .bash_profile carregamos as novas configurações com o comando source.

Se você chegou até aqui não esqueça de deixar o seu ❤ e/ou um comentário. Se você tem interesse por Laravel ou gostou do meu texto você pode ler algum dos meus outros artigos, recomendo:

1. PHP — Implementando adminLTE no Laravel 5.4
2. PHP — Criando um CRUD com Laravel 5.4
3. PHP — Relacionando Models e Tabelas no Laravel 5.4
4. Docker — Dockerhub, pull e push nas suas imagens

See you, Space Cowboy!