Qual abordagem você usam quando fazem TDD?

Assuntos Gerais
#1

Estou começando a estudar sobre TDD e venho fazendo alguns projetinhos pessoais para praticar e uma dúvida recorrente que tenho é sobre as validações(Validação de formulário no front-end, Validação de request das API’s no back-end). Vendo palestras sobre TDD eu vi as 3 regras que devemos aplicar ao TDD:

  1. Escreva o código apenas para passar em um teste falhando.
  2. Não escreva mais em um teste do que o suficiente para falhar.
  3. Não escreva mais código do que o necessário para passar no teste que esteja

Bem, se eu quiser seguir TDD seguindo essas 3 regras a risca, isso me obriga a fazer os testes de validação do tipo, testes para verificar se um único campo é obrigatório, verificar se o tamanho do valor é maior ou menor que o permitido, entre outros tipos de testes de validação.
Tenho amigos que trabalham com programação e me aconselharam a fazer apenas os testes da lógica de negócio, porque os testes de validação são testes frágeis e tornam o código mais engessado e dificulta alterações no código, porque mecher no código de produção implica em alteração no código dos testes.
Por outro lado tenho amigos que dizem que devemos sim escrever os testes de validação e que o fato de você alterar o código e ter que fazer a manutenção não deveria ser considerado como lado negativo, pois essa é a função dos testes, mostrar que a lógica foi alterada.

Minha dúvida é que abordagem vocês usam? Testes de validação são realmente testes frágeis e desnecessários?

#2

Nao uso TDD. Na minha opinião perda de tempo pra requisitos funcionais.

Sobre testes durante o desenvolvimento, é o natural feedback com o cliente. E a equipe de qualidade usa testes funcionais automatizados.

1 curtida
#3

Eu concordo mais com o seu segundo grupos de amigos.
Testes são usados pra garantir/documentar o comportamento de uma aplicação. Se o comportamento muda, o teste tem que mudar também.

Eu chamaria de testes frágeis aqueles que quebram quando o comportamento não muda. Você faz um refactoring, e o teste quebra. Aí é mal sinal.
Outro teste ruim é aquele que nunca quebra, mesmo quando muda o comportamento.

Uma outra coisa boa de se evitar é que vários testes quebrem quando você altera apenas uma coisa.
Quando isso acontece, dar manutenção nos testes passar a tomar muito tempo e o valor deles passa a ser discutível.

1 curtida