O Desenvolvimento Orientado por Testes (por vezes designado por Desenvolvimento Guiado por Testes ou Design Orientado por Testes) é a prática de escrever os testes unitários primeiro, antes de escreveres uma única linha de código de implementação.
No Exercism, os testes são os requisitos!
Todos os Exercícios de Prática em que trabalhas (aqueles que não te ensinam um novo conceito) têm instruções que descrevem, em termos gerais, o que precisas de fazer.
Por opção, estas instruções não contemplam detalhes de implementação específicos de cada linguagem de programação, porque são partilhadas por todos os mais de 70 percursos de linguagem do Exercism.
Alguns percursos de linguagem acrescentam detalhes mais específicos para ti, mas não todos.
Quando começas a trabalhar num Exercício de Prática, lê as instruções com atenção.
Dão-te uma visão geral de como hás de implementar uma solução.
Mas tens de ler os testes para perceberes todos os requisitos exatos:
- O resultado tem de ser um determinado tipo de estrutura de dados?
- O resultado tem de estar ordenado por alguma ordem?
- Como é que se espera que lides com exceções? E por aí adiante.
Resolveste um exercício quando todos os testes fornecidos correm e passam.
Por outras palavras, a tua solução não é apenas uma interpretação das instruções que «parece certa», a tua solução é um programa que satisfaz os testes fornecidos.
Os testes representam os requisitos completos do exercício.
Como é que o Exercism aplica o TDD?
Já fizemos o trabalho de escrever um conjunto de testes unitários para ti.
O teu objetivo é escrever uma solução que contenha apenas o código suficiente para fazer passar todos esses testes unitários.
Tem isto em conta: a abordagem TDD ajuda-te a chegar à solução, mas não precisas de ficar por aí.
Se quiseres ir além dos requisitos, estás à vontade para o fazer.
Se decidires trabalhar com um mentor (e encorajamos-te a fazê-lo assim que os testes passarem), ele pode ajudar-te a refatorar e a aperfeiçoar a tua implementação inicial, ou até propor novos testes unitários.
Trabalhar no editor online
Quando estás a trabalhar no editor de código do site do Exercism, consegues ler os testes, mas não os consegues editar.
Todos os testes são executados sempre que os corres, independentemente de quaisquer mecanismos de ignorar testes indicados no ficheiro de testes.
Quando há vários testes que falham, o site mostra inicialmente apenas o resultado da primeira falha.
Também podes clicar noutras falhas para as expandir!
Por vezes, o primeiro resultado pode não ser o mais informativo.
Não te desanimes com um grande número de testes a falhar.
Concentra-te em fazê-los passar um a um.
Trabalhar localmente
Muitos percursos usam testes «ignorados» nos seus ficheiros de teste.
Inicialmente, só o primeiro teste está «ativo» e os restantes estão inativos (a forma como isto acontece varia de percurso para percurso).
Quando corres o conjunto de testes no teu ambiente, só o primeiro teste é executado.
Fazemos isto para te incentivar a seguir este fluxo de trabalho:
- Antes de acrescentares código novo, corre o conjunto de testes: deves ver um teste a falhar.
- Acrescenta o código estritamente necessário para passar o teste.
- Corre o conjunto de testes.
- Se o teste continuar a falhar, repete o passo 2.
- Assim que o teste passar, refatora o teu código como quiseres, garantindo que todos os testes ativos continuam a passar.
A refatoração pode incluir:
- remover código duplicado,
- dividir funções longas em funções mais pequenas,
- acrescentar comentários, etc.
- Deixa de ignorar o próximo teste e repete a partir do passo 1.
Repete estes passos até deixares de ignorar todos os testes.
Assim que todos os testes passarem, parabéns, resolveste o exercício!
A forma exata como os testes deixam de estar ignorados (ou são ativados) depende do percurso.
Em alguns percursos, pode passar por comentar ou remover uma anotação.
Em alguns percursos, pode passar por mudar um atributo de true para false.
Reserva um pouco de tempo para ler a documentação do teu percurso; lá encontrarás estes detalhes.
Nos percursos que não ignoram os testes, aplicar este fluxo de trabalho pode ser tão simples como comentar os testes e descomentá-los um a um.
Razões para usar o Desenvolvimento Orientado por Testes
Embora possa parecer que estamos a «pôr o carro à frente dos bois», há várias boas razões para escreveres os testes unitários antes do código de implementação.
-
Conceção.
Obriga-te a pensar primeiro na interface do teu programa (na forma como expõe a sua funcionalidade ao mundo), em vez de saltares logo para a forma como vais implementar o código.
Ter uma interface bem desenhada (e testável!) é muitas vezes mais importante do que ter uma implementação eficiente.
-
Disciplina.
Escrever testes é muitas vezes visto como uma tarefa aborrecida ou um pensamento de última hora; escrever os testes primeiro garante que, no fim do dia, terás escrito testes unitários suficientes para cobrir a maior parte, ou a totalidade, da funcionalidade do teu código (em vez de nunca chegares a fazê-lo).
-
Menos trabalho.
Se aplicares um ciclo apertado de escrever um teste, depois escrever o código que o implementa e, em seguida, escrever o teste seguinte, o teu código acaba por crescer de forma orgânica.
Isto conduz muitas vezes (embora nem sempre) a menos esforço desperdiçado: acabas por escrever todo o código de que precisas e nenhum do que não precisas.
Leitura adicional
