MouseOver Studio

Já faz um tempo que sou apaixonado por especificações executáveis vulgo testes. Constantemente tento melhorar minhas especificações e testes lendo ao respeito e vendo os testes de outras pessoas. Nessa rutina me encontro frequentemente com testes que me deixam muito a desejar e que podem melhorar muito simplesmente seguindo o padrão um assert/expectativa por teste.

Antes de justificar por que eu acho que o padrão deve ser seguido, vou dizer que especificação e teste são para mim duas coisas diferentes, mas são duas coisas que se complementam. Nada melhor para me explicar que com exemplos:

it "should find customers by a given name" do
  ...
end

test "customers are found by a given name" do
  ...
end

public void testCustomersAreFoundByAGivenName() {
  ...
}

Nos três blocos acima, em todos os casos temos um requisito ou especificação do nosso sistema (”os clientes devem ser encontrados dado um nome”) e um código ou teste (”…”) que verifica que esse requisito/especificação esta sendo satisfeito. Podemos chamar o conjunto inteiro de teste mesmo, mas é importante não esquecer de que nele devemos ter uma especificação.

Somente como anedota, tem muitas vezes que baixei o código fonte de algum framework ou api somante para ver os testes e poder saber o que o código pode e não pode fazer. Os testes podem e devem ser muito informativos.

Mas por que estou falando isso? Estou falando isso porque esse comportamento desejado é muito fácil de se alcançar se você seguir o padrão um assert/expectativa por teste. Seguindo esse padrão você vai ter mais blocos de testes, então você vai ter que nomear mais vezes o que o teste ira validar e para não repetir nomes automaticamente você terá que ser mais específico, o que ira criar uma especificação mais detalhada.

Do meu lado esta a ultima Java Magazine, vou pegar o primeiro teste que encontrar na revista como exemplo:

test "enviar relatorio" do
  envio_mail = EnvioEmail.new("morena@opensource.com")
  assert_true envio_email.enviar
  assert_equals envio_mail.texto_mensagem, "Testes executados com sucesso"
  assert_equals envio_mail.get_titulo, "Resultado testes"

  esperado = Arquivo.new("xpto.zip")
  enviado = envio_email.arquivo_mensagem
  assert_equals esperado, enviado
end

Antes de aplicar o padrão, qual é o problema com o teste anterior? Imaginemos que estamos executando nosso teste y no terminal aparece que o teste “enviar relatório” falhou. Se eu vejo isso vou pensar que o relatório não foi enviado, mas ele foi! O teste pode ter falhado porque no título se esperava “Resultado testes” e se obteve “Resultado testes.”, com um ponto a mais. O teste não esta somente testando se o relatório foi enviado, esta também testando se ele foi enviado com o título certo, só que o nome não diz isso. Se vendo os testes, nenhum diz que o relatório deve ser enviado com o título certo, posso considera lo como um requisito? Se é um requisito, onde esta escrito? Tenho que ficar analisando dentro dos testes para saber o que o sistema deve ou não fazer? Se não é um requisito, porque esta invalidando o teste?

Aplicando o padrão mencionado no exemplo ele ficaria mais ou menos assim:

antes :todos do
  envio_mail = EnvioEmail.new("morena@opensource.com")
end

test "relatório é enviado" do
  assert_true envio_email.enviar
end

test "relatório é enviado com o texto certo" do
  assert_equals envio_mail.texto_mensagem, "Testes executados com sucesso"
end

test "relatório é enviado com o título certo" do
  assert_equals envio_mail.get_titulo, "Resultado testes"
end

test "relatório é enviado com o arquivo certo" do
  esperado = Arquivo.new("xpto.zip")
  enviado = envio_email.arquivo_mensagem
  assert_equals esperado, enviado
end

Não ficou bem melhor?

Agora, supondo que o problema não foi corregido, ao executar os testes vamos receber que o requisito “relatório é enviado com o título certo” não esta sendo satisfeito, mas ao menos sabemos que isso é um requisito e rapidamente podemos identificar que parte do processo “enviar relatório” não esta correto.

Pensando agilmente, esse requisito que não passou pode não representar muito valor para o cliente. O maior valor para o cliente pode estar em enviar o email mesmo e o teste diz que o email esta sendo enviado, pelo que o cliente poderia aceitar o software e não esperar ate que os outros requisitos que não geram tanto valor sejam satisfeitos.

Mais informação sobre o padrão pode ser encontrado aqui nesse post do Jay Fields. Foi o post que me convenceu de seguir esse padrão e desde ai o venho utilizando.