No artigo [Por que TDD?](/2016/10/por-que-tdd.html) eu escrevi sobre alguns beneficios de usar TDD, mas foi um texto bem conceitual, sem exemplos. Nesse aqui eu quero mostrar um dos beneficios de testes automatizados na pratica: servir como documentacao tecnica funcional.Leia com atencao o trecho de codigo abaixo: um_mes_atras = datetime.date.today() - timedelta(days=30) URL = ( "/ferias/cancelar_ferias_nao_aprovadas_marcadas_antes_de?data=%s" % um_mes_atras.strftime("%Y%m%d") ) class TestClientCancelarMarcacaoDeFeriasNaoAprovadas(django.test.TestCase): def test_url_get_retorna_http200_qdo_ha_ferias_antigas_nao_aprovadas(self): p = apoio.criar_profissional() apoio.criar_ferias( profissional=p, marcado_em=datetime.date.today() - timedelta(days=60), aprovado=False ) response = self.client.get(URL) self.assertEqual(200, response.status_code) def test_url_get_retorna_http404_qdo_so_ha_ferias_recentes(self): p = apoio.criar_profissional() apoio.criar_ferias( profissional=p, marcado_em=datetime.date.today() - timedelta(days=10), aprovado=False ) response = self.client.get(URL) self.assertEqual(404, response.status_code) def test_url_get_retorna_http404_qdo_so_ha_ferias_aprovadas(self): p = apoio.criar_profissional() apoio.criar_ferias( profissional=p, marcado_em=datetime.date.today() - timedelta(days=90), aprovado=True ) response = self.client.get(URL) self.assertEqual(404, response.status_code)Certamente esse codigo poderia -- e deveria! -- ser melhorado para rodar em um sistema real. Ele esta bem resumido aqui apenas para servir de exemplo.Se voce ja programou para web e leu o codigo acima com atencao tera mais facilidade para entender o que ele faz. Vamos ver o que conseguimos descobrir sobre a URL `/ferias/cancelar_ferias_nao_aprovadas_marcadas_antes_de` sem olhar o codigo fonte dela.Pelo nome da classe e pelo conteudo da variavel `URL` conseguimos perceber que estamos testando uma funcionalidade que cancela ferias ainda nao aprovadas e que foram marcadas antes de determinada data. Descobrimos que precisamos passar `data` como argumento da URL.Na classe de teste exercitamos dois comportamentos basicos:1. Se a funcionalidade retorna status HTTP 200 quando existirem marcacoes de ferias antigas e nao aprovadas.1. Se a funcionalidade retorna status HTTP 404 quando nao existirem marcacoes de ferias antigas e nao aprovadas.Os testes deixam claro que as ferias nao podem existir sem um profissional.Conseguimos inferir que "ferias antigas" sao todas as que foram marcadas antes de `data`, que e um argumento passado na URL.Traduzindo para Portugues:1. Se existirem ferias marcadas antes de `data` e que nao foram aprovadas, a funcionalidade deve retornar status HTTP 200.1. Caso contrario, deve retornar status HTTP 404.Nesse exemplo simples percebemos que testes automaticos servem para certificar que seus programas funcionam da forma esperada e tambem ajudam a entender o que o sistema faz. Essa e a utilidade das documentacoes.Testes automaticos (principalmente _test first_) precisam ajudar a deixar o codigo mais claro e mais simples. Se voce tambem usar nomes significativos para variaveis, classes e metodos de teste, logo percebera como fica mais facil entender o sistema, mesmo sem olhar a logica interna das rotinas. Isso ajuda bastante a quem for mexer no sistema. Lembre-se que esse alguem pode ser voce, daqui a alguns meses ou alguns anos.Finalizando, escreva testes automaticos, use nomes significativos neles e tenha um tipo de documentacao tecnica que ajuda a checar o funcionamento do sistema.------------------------------------Agradecimentos: quero agradecer a [Jessica Temporal](http://twitter.com/jtemporal), ao [Eduardo Klosowski](https://eduardoklosowski.wordpress.com/) e ao [Diego Sorrilha](http://twitter.com/diegosorrilha) pelo tempo dedicado revisando e melhorando o texto.Existem [outros textos sobre testes](/search/label/tests) aqui no blog. Aproveite para le-los. TDD e uma das praticas basicas do [Extreme Programming](http://www.extremeprogramming.org/index.html) (XP), que, por sua vez, e uma das abordagens para desenvolvimento agil de software. Por causa disso, muitas pessoas pensam assim:> "Metodologia agil" chama-se "agil", porque significa "mais rapido". Portanto, se TDD faz parte disso, vai fazer de mim