Automatizando testes de software

O PHPUnit é a ferramenta padrão de testes no PHP, e após várias
tentativas anteriores de como explicar testes automatizados em 50 minutos
chegamos a essa iteração da tentativa, que:

Explica como criar sua própria ferramenta de testes
Como testar uma aplicação existente
Como transportar nossos testes para o PHPUnit

Meu objetivo com essa estrutura é mostrar que você já sabe testar. Minha
hipótese é que mostrando como automatizar um teste sem nenhuma ferramenta fica
mais fácil entender como usar o PHPUnit.

Você já sabe testar

Automatizar testes não é tão óbvio quando pode parecer e é bem difícil escrever
bons testes – justiça seja feita que é difícil até definir o que é um bom
teste. A receita pra isso é tentar, falhar e aprender com isso. Levei mais de 5
anos pra me sentir confortável com o conceito.

Você sempre checa se o que você fez funciona ou não, isso é testar. É normal
escutar pessoas dizendo que “não sabem testar” quando na verdade elas querem
dizer que não sabem fazer isso de forma automática. A exemplo o teste abaixo:

$ echo "Hello World!"
Hello World!

O output é exatamente o esperado então o teste é um sucesso! Falhas podem
acontecer de diversas formas:

$ echp "Hello World!"
-bash: echp: command not found

O output do comando acima é uma falha, por exemplo. Se você que automatizar
seus testes precisa aprender que eles possuem basicamente duas condições:
sucesso ou falha.

Automatizando nossa primeira verificação

Automatizar significa criar um programa que faça essa verificação sozinho pra
nós e nos diga se tudo deu certo ou não. Daí vem a primeira confusão:

Uma verificação (assertion) pode ter sucesso ou falha
Um teste pode ter sucesso ou falha

Um teste pode ser composto por várias verificações e se uma verificação
falha o teste falha como consequência. Para automatizar o um teste precisamos
saber quais verificações podemos ou iremos fazer, seguindo o exemplo anterior
podemos verificar:

O output é igual ao esperado?
O comando sendo executado existe?
O comando é executado com sucesso?

A mim, a lista de verificações passíveis de automatização são uma das tarefas
mais difíceis e que nenhum framework de teste unitário irá fazer por você.
Implementar todas as verificações é uma excelente ideia mas com o tempo você
nota que existe um ideal e o ideal agora é só verificar se o comando é
executado com sucesso.

Toda shell, ao executar um comando, popula a variável $? com 0 (zero) caso
sucesso e é nesse comportamento que vamos verificar todo nosso comportamento:

$ echo "a"
a
$ echo $?
0
$ echp "a"
-bash: echp: command not found
$ echo $?
127

Sabendo o que precisamos verificar, podemos escrever nosso teste. Ele será
um programa shell que terminará com 0 (zero) no caso de sucesso além de
imprimir “ok”.

#!/usr/bin/env sh

# 1. Executa o comando
# O `> /dev/null` faz com que o output do comando não seja exibido
echo "Hello World!" > /dev/null
# 2. Verificamos a saida
if [ "$?" == "0" ]
then
    # 3. Imprime sucesso
    echo "Ok"
    # 4. Sai com status 0 (zero) de sucesso
    exit 0
else
    # 3. Imprime erro
    echo "Error"
    # 4. Sai com status 1 (um) de erro
    exit 1
fi

Toda vez que executarmos o programa acima, ele fará a verificação de forma
automática. Apesar do programa acima não parecer muito útil, ele é a estratégia
que todas as ferramentas de Integração Contínua usam: verificar o exit code
de um comando. Apesar dele não parecer muito útil, você aprendeu uma lição
fundamental para fazer seu próprio sistema de integração contínua.

Automatizando a execução das verificações

É aqui que a maioria dos frameworks de teste entram. Apesar deles já possuírem
diversas ferramentas que auxiliam na verificação, o que eles inicialmente
provêm é uma forma de organizar suas verificações e de executar elas.

O PHPUnit, por exemplo, trata todas as classes com sufixo Test e que
herdam PHPUnitFrameworkTestCase como uma suíte (conjunto) de testes e todo
método com o prefixo test como um teste. Se nós quisermos algo semelhante,
precisamos:

Definir uma estrutura padrão de teste
Executar todos os testes que seguem essa estrutura
Produzir um relatório dos testes

A estrutura que nossos testes terão é simples e eficiente, e não muito
diferente do que várias ferramentas oferecem:

Todo teste deve estar dentro do diretório test
Um teste por arquivo, o nome do arquivo é o nome do teste
O teste não deve imprimir nada
O exit code do teste é o resultado dele

Agora precisamos de um programa para executar todos os testes. Esse programa,
assim como nossa verificação automatizada e nossos testes, irá terminar com
exit code 0 (zero) em caso de sucesso.

$ ls tests/*.sh
tests/hello.sh

O ls acima irá listar todos os arquivos .sh dentro do diretório tests,
podemos usar a saída desse comando em um for que será executado para cada item
encontrado:

#!/usr/bin/env

# 1. Busca todos os testes existentes
for test in $(ls tests/*.sh)
do
    # 2. Garante que o teste possa ser executado
    chmod a+x "${test}"
    # 3. Executa o teste
    $test > /dev/null
    if [ "$?" != "0" ]
    then
        # 4. Saída com status 1 (um) de erro
        exit 1
    fi
done
# 4. Saída com status 0 (zero) de sucesso
exit 0

Agora não importa quantos testes tenhamos no diretório tests, sempre que
executarmos o programa acima vamos ter o resultado de sucesso caso todas as
nossas verificações passem.

Falta fazer a parte de relatório, mas acho que você já pegou as manhas do que
estamos fazendo. Existem padrões de relatório de testes automatizados:

xUnit é um formato em XML que costuma ser o padrão aceito
TAP é um formato mais verboso e mais apropriado para humanos
TestDox é um padrão para nome de testes que é usado como relatório também

Esses formatos padrão de relatório de execução são importantes só para
integração com outras ferramentas, que normalmente são ferramentas de
Integração Contínua.

Para onde continuar?

Existe um vídeo deu apresentando essa ideia e como usar o PHPUnit para
automatizar seus testes que vai um pouco além do escrevi aqui.

Recomendo alguns livros também:

GOOS: Cria um software usando TDD num passo-a-passo bem fácil de entender
TDD: Descreve a técnica de criar testes automatizados antes da
implementação e como isso pode melhorar sua vida

Se você quiser qualquer dica, ou tiver alguma crítica ou sugestão, dê um toque!
Se eu puder der uma dica a você que nunca fez um teste automatizado ela é a de
começar logo. Além da curva de aprendizado natural, leva um tempo aprender que
nem todo código é automaticamente testável e mais tempo ainda em como fazer isso
e os livros acima ajudam bastante a reduzir esse tempo.

Perguntas frequentes

Como eu convenço meu chefe de que isso é importante?

No começo desse post eu tentei explicar que você faz isso de um jeito ou de
outro. Começar a fazer testes de maneira automática reduz o seu trabalho e
se tudo der certo você vai começar a entregar trabalho com mais qualidade.

Se você precisa aprender a fazer testes automáticos, daí a conversa com seu
gestor é outra.

Como eu testo algo que já existe e o código é ruim?

Você pode usar testes de comportamento para testar a aplicação inteira.
Eles são mais lentos e precisam de algumas condições anteriores (usuário
existir, produto, etc) mas vão entregar valor rápido e costumam ser mais simples
de entender e fazer no início.