O que não é um teste unitário

Muito interessante este post do Michael Feathers sobre o que não é um teste unitário:

Um teste não é unitário se...

...Acessa o banco de dados
...Comunica através da rede
...Grava/acessa arquivos no file system
...Não pode ser executado em paralelo com outros testes unitários
...Você precisa fazer coisas especiais como alterar arquivos de configuração, para executá-lo.

O seu argumento é que testes que façam as coisas acima não são ruins, mas também fogem da idéia principal que é testar código, quando nós começamos a misturar código de testes com acesso a bancos de dados, por exemplo, temos uma série de problema como capacidade de repetir os testes, simular erros e verificar se o problema está no código ou no sistema com o qual você está interfaceando.

Não que este tipo de teste não precise ser escrito, é que os testes unitário puros são muito subvalorizados.

Eu cometo todos estes erros e concordo com ele, apesar de achar um pouco de exagero o último item. A solução clara para estas limitações é trabalhar com Mock ou Fake Objects.

Por exemplo, ao testar um código de CRUD (create-read-update-delete) eu poderia criar uma classe falsa que contém um DataSet moldado com todas as variações de registros de uma tabela do meu banco de dados, como é uma representação em memória os testes irão executar rápido, sempre com resultado previsível e sem atrapalhar outros desenvolvedores.

É claro que eu precisaria de uma maneira de substituir a minha classe de acesso a dados para chamar a classe falsa ao invés do banco de dados verdadeiro, mas isso pode ser uma tarefa simples se você utilizar frameworks como o Enterprise Library ou o NHibernate que têm suporte para chamar classes parametrizadas em arquivos de configuração.

No próximo post coloco um exemplo prático, com código.