O Desenvolvimento Guiado por Testes (às vezes chamado de Desenvolvimento com Testes Primeiro ou Design Guiado por Testes) é a prática de escrever os testes de unidade primeiro, antes de escrever 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 você trabalha (aqueles que não ensinam um conceito novo) terão algumas instruções que descrevem, em termos gerais, o que você precisa fazer.
De propósito, essas instruções não levam em conta detalhes de implementação específicos de cada linguagem de programação, porque são compartilhadas pelas mais de 70 trilhas de linguagens do Exercism.
Algumas trilhas acrescentam detalhes mais específicos para você, mas nem todas fazem isso.
Quando você começar a trabalhar em um Exercício de Prática, leia as instruções com atenção.
Elas vão te dar uma visão geral de como implementar uma solução.
Mas você vai precisar ler os testes para entender os requisitos completos e exatos:
- O resultado precisa ser um tipo específico de estrutura de dados?
- O resultado precisa estar ordenado de alguma forma?
- Como você deve tratar exceções? E assim por diante.
Você resolveu um exercício quando todos os testes fornecidos rodam e passam.
Em outras palavras, sua solução não é apenas uma interpretação das instruções que "parece certa"; sua solução é um programa que satisfaz os testes apresentados.
Os testes representam os requisitos completos do exercício.
Como o Exercism aplica o TDD?
Nós fizemos o trabalho de escrever uma suíte de testes de unidade para você.
Seu objetivo é escrever uma solução que contenha o código suficiente para fazer todos esses testes de unidade passarem.
Tenha isso em mente: a abordagem de TDD vai te ajudar a chegar à solução, mas você não precisa parar por aí.
Se você quiser estender sua solução além dos requisitos, fique à vontade.
Se você escolher trabalhar com um mentor (e nós incentivamos que faça isso assim que os testes passarem), ele pode te ajudar a refatorar e aprimorar sua implementação inicial, ou até propor novos testes de unidade.
Trabalhando no editor online
Quando você está trabalhando no editor de código do site do Exercism, você pode ler os testes, mas não pode editá-los.
Todos os testes serão executados sempre que você rodá-los, independentemente de quaisquer mecanismos de ignorar testes indicados no arquivo de teste.
Quando há vários testes que falham, o site inicialmente mostra apenas o resultado da primeira falha.
Você também pode clicar nas outras falhas para expandi-las!
Às vezes, o primeiro resultado pode não ser o mais informativo.
Não se desanime com um grande número de testes falhando.
Foque em fazer com que passem, um de cada vez.
Trabalhando localmente
Muitas trilhas usam testes "ignorados" em seus arquivos de teste.
Inicialmente, apenas o primeiro teste está "ativo" e os demais estão inativos (como isso acontece varia de trilha para trilha).
Quando você roda a suíte de testes no seu ambiente, apenas o primeiro teste roda.
Fazemos isso para incentivar você a seguir este fluxo de trabalho:
- Antes de adicionar qualquer código novo, rode a suíte de testes: você deve ver um teste falhando.
- Adicione o código suficiente para passar no teste.
- Rode a suíte de testes.
- Se o teste ainda falhar, repita o passo 2.
- Assim que o teste passar, refatore seu código como quiser, garantindo que todos os testes ativos ainda passem.
A refatoração pode incluir:
- remover qualquer código duplicado,
- dividir funções longas em funções menores,
- adicionar comentários, etc.
- "Remova a marcação de ignorado" do próximo teste e repita a partir do passo 1.
Repita esses passos até que todos os testes estejam ativos.
Assim que todos os testes estiverem passando, parabéns, você resolveu o exercício!
A forma exata de deixar de ignorar os testes (ou ativá-los) depende da trilha.
Em algumas trilhas, pode ser comentar ou remover uma anotação.
Em outras, pode ser mudar um atributo de true para false.
Reserve um tempo para ler a documentação da sua trilha; ela explicará esses detalhes.
Para as trilhas que não ignoram os testes, aplicar este fluxo de trabalho pode ser tão simples quanto comentar os testes e descomentá-los um de cada vez.
Por que usar o Desenvolvimento Guiado por Testes
Embora possa parecer "colocar o carro na frente dos bois", há várias boas razões para escrever os testes de unidade antes de escrever o código de implementação.
-
Design.
Ele te obriga a pensar primeiro na interface do seu programa (como ele expõe sua funcionalidade para o mundo), em vez de partir direto para como você vai implementar o código.
Ter uma interface bem projetada (e testável!) costuma ser mais importante do que ter uma implementação eficiente.
-
Disciplina.
Escrever testes muitas vezes é visto como uma obrigação chata ou algo que se deixa para depois; escrever os testes primeiro garante que, no fim das contas, você terá escrito testes de unidade suficientes para cobrir a maior parte, ou toda, a funcionalidade do seu código (em vez de talvez nunca chegar a fazê-lo).
-
Menos trabalho.
Se você aplicar um ciclo bem apertado de escrever um teste, depois escrever o código que implementa esse teste e então escrever o próximo teste, seu código acaba crescendo de forma orgânica.
Isso muitas vezes (embora nem sempre) leva a menos esforço desperdiçado; você acaba escrevendo todo o código de que precisa, e nenhum código que não precisa.
Leitura adicional
