Como usar testes de unidade como fonte de informação?

Um colega meu esteve em um seminário sobre desenvolvimento ágil, onde ouviu que é possível usar testes de unidade como documentação técnica. Algo como usar testes de unidade como um exemplo de como usar a classe.

Uma rápida pesquisa no Google forneceu TDD e documentação , o que prova que isso é possível. Mas, olhando para o nosso código, vejo que obviamente não conseguimos implementar testes de unidade dessa maneira.

Na minha opinião, os testes de unidade existem para testar o código como uma unidade mínima, mesmo com a ajuda de classes e funções simuladas e falsas.

Então, as perguntas são:

• Não é tarefa dos testes funcionais mostrar como uma classe (ou conjunto de classes) deve ser usada?
• Se for possível usar testes de unidade como documentação técnica, existem algumas diretrizes sobre como implementar esses testes de unidade?

Se você estiver aplicando TDD, cada teste de unidade que você escreveu corresponderá à funcionalidade de uma classe. Então, ao escrever testes, você está realmente criando as funcionalidades da classe, dependências, exceções e também a documentação da classe.

Se você não está aplicando TDD, os testes de unidade ainda dão uma idéia sobre a classe e o que ela faz. Os nomes dos testes de unidade são muito descritivos, portanto você não precisa criar uma documentação principalmente.

Considere um teste de unidade como

public void Customer_Service_Can_Register_New_Customers(){...}
public void Customer_Service_Cannot_Register_Customers_With_Duplicate_Emails(){...}

Estes são métodos auto-descritivos e fáceis de ler também. Então eles também servem como documentação.

Os testes de unidade, se bem escritos, servem como documentação de uma classe ou método ou qualquer outra coisa.

Os bem escritos levam a mais compreensão por serem fáceis de descobrir o que estão testando, mas mesmo testes ruins dão ao leitor uma idéia de como a coisa que está sendo testada deve agir e quais coisas o autor achava importante testar.

Heck, sou conhecido por escrever testes de unidade para bibliotecas externas - não porque eles precisam de testes, mas porque quero garantir que meu entendimento da biblioteca esteja correto. E no futuro, se alguém tiver dúvidas sobre como estou usando as coisas, bem, aí está meu entendimento, diretamente no código do teste.

Embora os testes funcionais possam ajudá-lo a entender toda uma parte da funcionalidade, um teste de unidade pode ajudar a entender um pequeno escopo de código (como um único método).

Bons testes de unidade também servirão como boa documentação técnica e existem algumas coisas que podem ajudar a escrever testes bons, simples e úteis. Os dois pontos mais importantes que encontrei são

• Verifique se todos os seus testes são independentes. Você deve poder executar qualquer subconjunto de testes, em qualquer ordem.

• Certifique-se de testar apenas uma coisa em cada teste. Isso mantém seus testes específicos, simples, mas não quebradiços.

A idéia de testes como critérios / documentação de aceitação é excelente. No entanto, os testes de unidade tendem a se concentrar no design da arquitetura / código, e não nas histórias do usuário - tentar documentar casos de uso ou requisitos de nível superior pode ser complicado. Ainda não procurei muito nisso, mas o Behavior Driven Development pode ajudar com esse problema.

Acho exemplos muito mais fáceis de aprender do que a documentação e os testes de unidade servem muito bem. Não apenas isso, mas eles me mostram, por exemplo, o que NÃO fazer com uma unidade.

No entanto, eles não podem ser a única forma de documentação. É preciso perceber que todos os cérebros funcionam de maneira diferente. Acho que as pessoas que recomendam usar apenas os testes de unidade como sua documentação ou APENAS o código perdem completamente. Ainda mais pungente é o fato de que mesmo cérebros únicos aprendem coisas diferentes de diferentes mídias. Aprendo algo completamente diferente em um diagrama de classes do que apenas vendo código ou lendo documentos da API.

Mas no final das contas, se diagramas e documentos da API são tudo o que você tem, provavelmente eu estou ferrado. Eu preciso de exemplos Eu preciso ver algo sendo usado. Eu posso pesquisar o código para isso, e sem outros exemplos, é com isso que eu estou preso, mas isso nunca me diz tanto quanto um bom teste de unidade.

Hoje, testar é uma bagunça de terminologia, onde pessoas diferentes significam coisas ligeiramente diferentes, e as definições mudaram ao longo do tempo.

Por exemplo, o TDD costumava ser algo que agora é chamado de BDD. A distinção se deve ao fato de que o teste de unidade através do desenvolvimento orientado a teste é agora uma abordagem muito mais refinada aos métodos de teste (geralmente gerados por ferramentas automatizadas). O que costumava ser TDD era uma maneira um pouco mais grossa de testar unidades do tamanho de classes, o que eu acho que agora é chamado de teste funcional.

A idéia de que você pode usar (alguma forma de) teste é que você pode escrever um teste parecido com o que o usuário usaria uma unidade do seu código. Torna-se um exemplo para os documentos e um teste ao mesmo tempo.

Portanto, se você tivesse uma classe de rede simples (por exemplo). Em vez de testar cada método individualmente, você abordaria o teste de que a classe é a unidade que precisa ser testada. Em seguida, seu teste de unidade exercitaria a unidade inteira chamando o método para inicializar o objeto, configurando o host e a porta e chamando um método para enviar dados, possivelmente chamando também um método para receber.

Tudo o que pode caber em um único 'teste de unidade' que testaria o objeto, definindo-o em um estado configurado e fazendo com que ele fizesse algum trabalho. Testes de unidade adicionais o exercitariam com dados incorretos, mas você não precisa colocá-los na documentação.

Hoje, isso não é considerado teste de unidade, mas tudo se resume à sua definição de unidade.