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

TDD - Já faz parte da sua vida?

Feito por Marcello Cavazza

Enquanto o front pensa em RGB, o back pensa em RGR!

Nesse último mês eu tenho estudado bastante TDD e achei interessante trazer uma síntese do que eu vi. Segue o fio!

Disclaimer: Existem diversos tipos de testes, então para um artigo focado em trazer a ideia principal de realizar testes, não passarei com foco nos tipos de testagem.

O que é TDD?

 Eu mesmo já tive a mentalidade que primeiro se escreve um código e depois criamos um teste(Ou então nem criamos testes automatizados para poder entregar rápido a tarefa e somente testamos o que percebemos na hora do código). Errado!

 TDD é na realidade desenvolvimento direcionado a testes ou desenvolvimento conduzido por testes(Eu prefiro ler dessa forma).

Como é o jeito certo?

 Na minha visão para se realizar um bom TDD é importante saber duas coisas:

  • GWT(Given - When - Then)
  • RGR(Red - Green - Refactor)

GWT

 Um ponto base para realizar um código de testes é pensar no GWT(Given - When - Then).

 Ex: Dado(Given) X passagens e Y tamanho do vôo, quando(When) eu registro as passagens no vôo, então(then) espero conseguir registrar as passagens sem erros.
Ex em código:

void DadoXPassagensEYTamanhoDeVooDevoRegistrarPassagensComSucesso
         (int passagens, int capacidadeMaxDeVoo)
{
   Voo viagem = new Voo();
   viagem.Set(capacidadeMaxDeVoo);
   viagem.Register(passagens).Should().BeTrue();
}

 E claro que poderíamos ter outras verificações(como verificar que não está acontecendo um "Overbooking", vender mais do que existe de assento), mas o foco do teste é sobre registrar passagens com sucesso.

 Faça o seu teste focar em um cenário somente para facilitar a manutenção futura e de testes em testes temos uma aplicação sem muitos bugs em PRD hehe.

 Então após um teste podemos escrever outros testes separados desse método para simular situações onde o registro de passagem por exemplo da erro ou então acontece o overbooking, assim podemos cobrir diversas situações de acerto e de erros com cada teste focado em uma única situação.

RGR

 Agora que você sabe sobre GWT, bora aplicar esse conceito de montar a estrutura de um teste em um projeto com a prática de testes? Aí que você começa a usar o RGR(Red - Green - Refactor).

  1. Primeiramente começamos no R(Red), onde você escreverá quase que um pseudo-código, pois estará montando o teste antes mesmo de ter as classes e/ou métodos do seu objetivo final, assim vamos ver somente textos em vermelho(Red).
  2. Segundamente vamos para o G(green), após você aplicar os conhecimentos de GWT para montar sua estrutura de teste, será montado o código em si que realizará a ação desejada e o seu teste deverá passar, resultando em um sinal verde(Green) no terminal.
  3. Finalmente você possuindo o seu testes que montou e o código da aplicação, iremos partir para o R(Refactor), assim após o seu código específico ser montado para passar no teste, você o aprimora e roda os testes novamente para ver se tudo continua Ok.

 Assim repita o processo até ter todas as features que precisa no projeto com todos os testes possíveis e necessários para validar a cada parte montada do projeto.

Considerações finais:

 Pensa comigo qual o sentido de entregar um código que não sabemos a qualidade e/ou o nível de funcionamento das ferramentas para o usuário/cliente?
É ilógico!

 Além de ajudar a manter o projeto com menos bugs, ajuda muito na procura de falhas no projeto de forma rápida, pois se temos certeza que todas as partes do projeto são constantemente testadas, assim nenhum erro passará!

 Como eu disse no disclaimer, existem muitas formas de se montar testes e o meu foco era mais apresentar a ideia e pedir para você programador a dar um chance a essa bela prática.

mais testes = menos dor de cabeça = menos bugs = mais dinheiro

 Reflita nessa última frase pelo menos se eu não te convenci no resto do artigo. hehe

Carregando publicação patrocinada...
1

Faz menos parte do que deveria. Confesso que tenho bastante preguiça de aplicar em front-ends. Mas TDD é vida, já me salvou de muita enrascada, e me ajuda bastante a organizar minha forma caótica de trabalhar.

1

Hoje eu escrevo teste para as aplicações, mas não o TDD. Eu costumo fazer meus códigos da seguinte forma.

1 - Escrevo Tudo, sem muita arquitetura, separação de responsabilidade, nem nada disso, apenas codifico um linguição para ver se tudo que foi pensado irá funcionar.

2 - Funcionou tudo que previ, agora começo gerenciar o código (criar services, repositories, dependency injection, middleware se necessário, separar os métodos para unica responsabilidade, etc).

3 - Com os métodos possuindo uma unica responsabilidade começo pensar nos possiveis testes (nesse momento encontro alguns cenários que falha e vou corrigindo o código).

4 - Por fim passando todos os testes está pronto para o PR.

2

Eu fazia bem dessa forma que você comentou. Mas com o tempo experimentei inverter um pouco a ordem.

Antes de refatorar o código( criar as camadas e separar as responsabilidades ) eu tento criar alguns testes e após ter esses testes passando, vou pegando cada cenário do teste e vou ajustando e rodando o teste.

Dessa maneira eu tenho a garantia que o resultado esperado sempre será o mesmo.

1
2

O feito melhor que perfeito é pior.
o FEITO MELHOR QUE PERFEITO vai para produção com a promessa de voltar e ajustar e nunca mais volta.

Nesse caso apenas eu valido o que fiz e depois estruturo (pq se mostrar pro lider ai vai para prod zuado mesmo).