Executando verificação de segurança...
7

TDD. O Que É? Onde Vive? Como Que Instala?

O que é?

O TDD é uma sigla para “Test Driven Development”. Que traduzindo seria “Desenvolvimento orientado a testes”. Ou seja, a ideia é que você escreva os testes da aplicação antes mesmo de escrever o código em si.

Sim, foi isso mesmo o que você leu. Os testes vêm antes do código.

Mas porque eu faria isso?

Escrever os testes desta forma pode soar contra intuitivo no primeiro momento. Mas esta estratégia traz inúmeros benefícios. Garantindo maior qualidade, escalabilidade e praticidade na manutenção das suas aplicações.

E o motivo é muito simples. Ao escrever os testes primeiro, você estabelece como seu código deve se comportar e quais os resultados que ele deve ter. Assim é muito mais fácil manter sua aplicação concisa e evitar bugs.

E como faço? Tem que instalar isso?

O TDD não é uma ferramenta, mas sim uma prática de design de código. Ou seja, ele ajuda você a pensar sobre como o código deve ser estruturado e como ele deve se comportar antes mesmo de começar a escreve-lo. Trata-se principalmente de planejamento.

Portanto, pode ser usada em qualquer linguagem e com qualquer framework de testes. E para aplicá-lo basta seguir um ciclo muito simples, porém poderoso, de desenvolvimento.

Faça, faça certo, faça melhor

O TDD se baseia em um ciclo com três passos:

  • RED

    Primeiro, o teste deve falhar. Sim, falhar. Afinal você ainda não escreveu o código que esta testando, ou ele está incompleto. E também, isto é muito importante para evitar falsos positivos. Onde o testa falha, ou passa, pelo motivo errado.

  • GREEN

    Em seguida, escreva o código da forma mais simples possível e o veja passar. Quanto mais simples melhor, pois essas etapas devem ser feitas devagar. Um passo por vez. Evitando assim, deixar alguma coisa para trás.

  • REFACTOR

    Depois disso, se o teste passar e for necessário, refatore o código. E caso o teste falhe, refaça o ciclo.

É importante destacar que se deve seguir os passos corretamente e na ordem. E ver se o código falhou, ou passou, pelo motivo esperado é essencial para o TDD fazer efeito.

Mão no código

Talvez apenas ler não seja o suficiente. E para assimilar melhor os conceitos seja necessário um exemplo. Vou estar utilizando aqui a linguagem Javascript, e o framework Jest para os testes. Mas poderia ser feito o mesmo com quais quer outras tecnologias.

Então para ter um contexto, vamos imaginar uma situação, onde para um aluno ser contratado no estagio basta ele ser maior de idade e ter carteira de motorista.

Assim vamos começar pelo teste, definindo o que esperamos de comportamento e de resultado do código.

it("Deve passar se o aluno for maior de idade e tiver carteira de motorista", () => {
  const aluno = {
    nome: "Fulano",
    idade: 21,
    carteiraDeMotorista: true,
  };

  const estagio = new Estagio();
  const contratado = estagio.contratar(aluno);

  expect(contratado).toBe(true);
});

Como esperado na etapa RED. Ao executar este teste, ele falha. Pois ainda não existe a class Estagio. Assim seguimos para o próximo passo. Fazer o teste passar da forma mais simples possível.

class Estagio {
  contratar(aluno) {
    return aluno.idade >= 18 && aluno.carteiraDeMotorista;
  }
}

Com isso o teste está passando e finalizamos a etapa GREEN. Agora é hora de deixar a class mais limpa e bem estruturada.

class Estagio {
  #idadeMinima = 18;

  contratar(aluno) {
    const ehMaiorDeIdade = this.#oAlunoEhMaiorDeIdade(aluno);
    const temCarteiraDeMotorista = this.#oAlunoTemCarteiraDeMotorista(aluno);

    return ehMaiorDeIdade && temCarteiraDeMotorista;
  }

  #oAlunoEhMaiorDeIdade(aluno) {
    return aluno.idade >= this.#idadeMinima;
  }

  #oAlunoTemCarteiraDeMotorista(aluno) {
    return aluno.carteiraDeMotorista;
  }
}

Em fim, finalizamos o passo REFACTOR. O teste está passando perfeitamente, e não existe mais nada a melhorar no código. Podemos então seguir para o resto da aplicação e refazer o processo.

Ao fim

Em suma o TDD é uma estratégia para garantir a qualidade do seu código. E de brinde, torna o desenvolvimento e a manutenção de qualquer aplicação muito mais fácil e menos estressante. Pois, os testes manterão sua aplicação bem estruturada. E quando você fizer alguma alteração no código, eles vão lhe avisar se houver um comportamento inesperado.

Outra coisa, é que a sua prática é considerada requisito para bons programadores no mercado. E quem testa, aprova. No começo você pode sentir certa dificuldade, principalmente se já está acostumado a fazer os testes por último. Ou, nem fazer, não é verdade? Mas em pouco tempo se tornará algo natural, e até vai se perguntar o porquê de não ter começado antes.

Referencias

Carregando publicação patrocinada...
1

Pô, belo artigo, achei simples e fácil de entender. O que acha da ideia da galera que pula as etapas k?, o primeiro teste sempre vai ser red, teoricamente não faz sentido o executar se sempre o resultado é o mesmo. Perceba que eu não estou questionando a eficacia do metodo e sim o ser humano que vai ser vencido pelo cansaço/preguiça e pular essa etapa.

1

Obrigado pelo elogio ivan. E essa sua pergunta é ótima.
Realmente a primeira execução do teste parece bem inutil. Pois sempre vai falhar ja que o código ainda não existe. Mas é importante lembrar que a etapa RED não acontece só na primeira execução. Quando vc for complementar um teste, por exemplo, essa etapa pode acontecer varias vezes. E pular essa parte pode gerar erros.
Na verdade o foco não esta em apenas ver o teste falhar. Mas sim, verificar se ele esta dando o erro esperado. Ou na etapa GREEN, verificar se ele esta passando pelo motivo certo.
Dessa forma evitamos que os testes sejam falsos positivos. E acredite, é muito facil isso acontecer. Mesmo se vc ja for craque em testes.

1