Contar história da minha experiência com TDD.
Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD.
Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD.
O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário.
Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
Contar história da minha experiência com TDD.
Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD.
Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD.
O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário.
Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer;
- Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
Vantagens:
Maior qualidade de código e da aplicação no geral
Exercita a refatoração – Te permite arriscar a escrever melhores códigos, arriscar padrões
Compreensão do modelo negocial – Por incrível que pareça, você passa a compreender melhor o negócio quando pensa nas possibilidades de teste antes de desenvolver
Rastreabilidade negocial – Te permite adicionar novas regras, novos métodos, novas funcionalidades, garantindo que as antigas ainda funcionam.
Desvantagens:
Curva de aprendizado – Se educar a usar TDD, compreender os conceitos
Complexidade – Pensar mais em modularização, código mais clean
Demanda mais tempo – Inicialmente você irá gastar mais tempo para desenvolver a solução, mas após compreender
- Método criado sem implementação
Implementação do teste para validar aquele método; o teste falha
Implementação minima do método a ser testado
Teste agora passa
A partir daí, chegamos na Terceira etapa, que é a refatoração, onde eu poderia adicionar validações no método, garantindo que o teste sempre irá passar, e caso falhe, continuo refatorando.
Vimos um exemplo muito simples e comum, mas e quando há mais camadas na classe a ser testada?
Nesse ponto complica um pouco, pois dependemos de uma camada dentro do método que queremos testar para nos retornar um determinado valor.
Podemos até implementar o repositório neste caso em memória, mas e quando ele for substituido pelo repositório real, como garantimos que este teste continuará funcionando?
Antes de explicar a solução para o problema anterior, precisamos falar sobre injeção de dependência.
Injeção de dependência tem como objetivo diminuir o acoplamento e facilitar o reuso.
Consiste em você fazer uma inversão de controles; ao invés de você instanciar uma classe, você passa essa responsabilidade para um builder que fará isso por você.
Dessa forma, programamos para interfaces, garantindo que uma classe não é afetada pela outra quando há modificações.
É simplesmente impossível utilizar TDD sem implementar injeção de dependência no seu projeto, o que faz dele um pré requisito