Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RealDay: Introduction to TDD

RealDay: Introduction to TDD

An introduction to TDD's concept and how it improves our software's quality.

Miguel Schmitz Grazziotin

April 04, 2014
Tweet

More Decks by Miguel Schmitz Grazziotin

Other Decks in Technology

Transcript

  1. 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 desejada 2. desenvolva o menor trecho possível de código para que o teste passe 3. refatore o código para torná-lo decente
  2. 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:
  3. História, O que é, O que não é TDD é

    especificação, não validação
  4. 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
  5. 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
  6. Comofaiz?! Boas práticas com TDD Para 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
  7. 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
  8. 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!
  9. 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
  10. 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
  11. 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”
  12. 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.
  13. TDD - Test Driven Development => Não é bala de

    prata, mas também vale muito! OBRIGADO! miguelgraz.com