TDD - Test Driven Development

A Bala de Prata da qualidade de software?

História, O que é, O que não é"Desenvolvimento orientado a testes" é um processo focado no constante ciclo:

1. escreva um pequeno teste que descreva a feature desejada2. desenvolva o menor trecho possível de código para que o teste passe3. refatore o código para torná-lo decente

História, O que é, O que não é

● "Test Driven Development: By Example" de Kent Beck, em 2003, falando sobre metodologias ágeis

● TDD é usado em conjunto com outros conceitos como extreme programming

● TDD definido por seus principais objetivos:

História, O que é, O que não é

TDD é especificação, não validação

História, O que é, O que não é => Especificação, não validação

● TDD usa as boas práticas de testes unitários para proporcionar e forçar o desenvolvedor a pensar no requerimento ou design antes de escrever código funcional

● “Entrega” testes unitários que ajudam na validação, mas isso é só uma boa consequência da prática

História, O que é, O que não é

TDD entrega código limpo e funcional

História, O que é, O que não é => Código limpo e funcional

● Premissa que o desenvolvedor sempre vai escrever o teste antes especificando o comportamento e trabalhar no menor trecho de código funcional possível

● Menos linhas de código = menos bugs● Mais testes = mais confiança e liberdade ao refatorar

Comofaiz?! Boas práticas com TDDPara termos o processo realmente funcional precisamos obedecer algumas pequenas mas importantes regras:

● O teste vem primeiro!

● Mantenha o código funcional pequeno, abuse de OO

● Trate seus testes com o mesmo respeito do seu código

Comofaiz?! Boas práticas com TDD

● O teste realmente precisa vir primeiro!

● Evite dependência entre testes, são partes autônomas

● Rode testes isolados, randomize quando rodar todos

● Use dados de fácil compreensão, cuide a legibilidade

● Crie testes que sejam um pequeno passo da feature completa, quando juntos eles cobrirão todo o código

Prós e Contras. Bom, mau e feio

Parece tudo muito bom, tudo muito bem, seguindo as práticas e entendendo do que se trata eu consigo fazer, mas antes de fazer quero saber dos resultados!

Prós e Contras => Bom

● Pequeno passo, teste que ele está ok, próximo pequeno passo. Muito código coberto por testes

● Código aos poucos > montes de código = produtividade

● Menos tempo de debug = produtividade

● Segurança para os desenvolvedores em refactors de código antigo e manutenibilidade

Prós e Contras => Mau

● É necessário bom entendimento do requerimento

● É parte da suite de testes, mas não é toda a suite

● Testes precisam ter manutenção, são parte do projeto, escreva-os bem

● Evite over-testing, quando o teste começa a ficar muito grande procure quebrá-lo em mais testes

Prós e Contras => Feio

● Acreditar que TDD “são só alguns testes”

● Ignorar a manutenção dos testes

● Acreditar que TDD substitui testes de integração, aceitação ou mesmo a documentação do projeto

● Testar depois de implementar a feature completa e achar que isso “é só o que precisa pra ser agile com qualidade”

Beija ou Passa?TDD é somente uma prática complementar de muitas boas práticas de desenvolvimento de software. Ele se vale de benefícios de testes unitários e da prática de escrever pouco código para refatorar.Deve ser adotado com apoio gerencial e cuidado dos desenvolvedores para seguir as regras esperadas.Com atenção e feito da maneira certa aumenta a produtividade e a qualidade do projeto de software.

TDD - Test Driven Development => Não é bala de prata, mas também vale muito!

OBRIGADO!

miguelgraz.com