TDD - Test Driven Development Introdução - PHP

1,690 views
1,479 views

Published on

Material de minha palestra realizada na Just Digital. Essa apresentação contempla apenas a introdução do TDD em PHP, focando nos conceitos mais fundamentais do TDD - Test Driven Development. A parte com exemplos práticos não foi inserida, mas não deve ser difícil encontrar tutoriais pela internet.

Boa leitura.

Published in: Technology

TDD - Test Driven Development Introdução - PHP

  1. 1. TDD Test Driven Developent
  2. 2. TDD – Test Driven Development Desenvolvimento Dirigido à Teste. Técnica de desenvolvimento de software onde os testes são implementados antes da solução ser codificada. Seu uso começou a ser popularizado com o XP, mas agora tem pernas próprias. Nenhum código é escrito a não ser para passar num teste que esteja falhando.
  3. 3. Por que testar? É notado que testes de software são importantes em projetos complexos. Tanto para mostrar que funciona agora, quanto para garantir que ainda funcionará no decorrer do desenvolvimento.
  4. 4. Por que TDD? Test Driven Development
  5. 5. Por que TDD? ▪ Os testes funcionam como uma documentação. ▪ Custa mais desenvolver testes tardiamente. ▪ O design do código é menos acoplado e melhor reutilizado. ▪ Funcionam também como testes de regressão. ▪ Aceitação de testes garantem conformidade com os requisitos. ▪ O desenvolvimento avança de forma incremental. Com passos mais fortes. ▪ Aumenta confiança no código. ▪ Breakdown dos requisitos em testes. ▪ Software mais modular e menos simbiótico. ▪ Escalabilidade e flexibilidade.
  6. 6. Desvantagens do TDD ▪ TDD é trabalhoso. Força os desenvolvedores a refatorar mais do que gostariam. ▪ Sua aderência pela equipe pode ser demorada. ▪ Mudança cultural nos processos.
  7. 7. Boas Práticas Test Driven Development
  8. 8. Boas Práticas ▪ Os testes são criados para provar que os requerimentos do sistema são atingidos. ▪ Garantir que todo código desenvolvido seja coberto por um teste. ▪ “Fake it, till you make it” - Kent Beck. ▪ Falhar primeiro! Para assegurar que o teste funciona. ▪ Mock Objects. Esses não podem ser superficiais. ▪ Métodos de Setup para facilitar a inicialização de itens comuns. ▪ Fixtures para emular um ambiente, estado ou contexto. ▪ Métodos de Teardown para limpar itens em memórias e banco de dados.
  9. 9. Más Práticas Test Driven Development
  10. 10. DDT DDT é o inverso do TDD: Testes Dirigidos ao Desenvolvimento. Em muitos projetos, quando os testes são implementados, apenas visam cumprir uma etapa do desenvolvimento. Quase que por formalidade. Feitos tardiamente, tendem a ter uma proposta mais otimista da solução. Normalmente deixam escapar variáveis importantes que asseguram qualidade e confiança do entregável. Prazo normalmente é mais apertado para criar e melhorar os testes.
  11. 11. Fazer o DDT ao invés de TDD. É equivocado, trabalhoso e ineficiente. Criar testes depois de desenvolver uma aplicação, serializa os processos de desenvolvimento e conflita com o ágil.
  12. 12. Fazer o DDT ao invés de TDD. Se a implementação for colocada à prova na reta final, a chance de retrabalho é ainda maior. Descobre-se tardiamente que a aplicação está muito acoplada e pouco testável. No entanto, já é tarde para mudar isso. O tempo não é bem aproveitado. Gera ilusão de que todos os requisitos do escopo estão sendo atendidos – mas não existem provas pra isso até então. E o deadline vira “linha da morte”.
  13. 13. Passos de TDD Test Driven Development
  14. 14. Passos do TDD 1. Crie um teste 2. Execute seu teste e veja-o falhar 3. Codifique um pouco 4. Execute os testes automatizados, esperando sucesso 5. Refatore o código 6. Repita
  15. 15. Crie um teste Em TDD, cada nova funcionalidade inicia com a criação de um teste. Este teste precisa inevitavelmente falhar porque ele é escrito antes da funcionalidade a ser implementada. Para escrever um teste, o desenvolvedor precisa claramente entender as especificações e requisitos da funcionalidade. Ele torna o desenvolvedor focado nos requisitos 'antes' do código.
  16. 16. Execute seu teste e veja-o falhar Esse passo valida se todos os testes estão funcionando corretamente e se o novo teste não traz nenhum equívoco, sem requerer nenhum código novo. Pode-se considerar que este passo então testa o próprio teste.
  17. 17. Codifique um pouco O próximo passo é escrever código que irá ocasionar ao teste passar. O novo código escrito até esse ponto poderá não ser perfeito e pode, por exemplo, passar no teste de uma forma não elegante. Isso é aceitável porque posteriormente ele será melhorado. O importante é que o código escrito deve ser construído somente para passar no teste; nenhuma funcionalidade (muito menos não testada) deve ser predita ou permitida em qualquer ponto.
  18. 18. Execute-os esperando sucesso Se todos os testes passam agora, o programador pode ficar confiante de que o código possui todos os requisitos testados. Este é um bom ponto que inicia o passo final do ciclo TDD.
  19. 19. Refatore o código Nesse ponto o código pode ser limpo como necessário. Ao re-executar os testes, o desenvolvedor pode confiar que a refatoração não é um processo danoso a qualquer funcionalidade existente. Um conceito relevante nesse momento é o de remoção de duplicação de código, considerado um importante aspecto ao design de um software.
  20. 20. Repita Iniciando com outro teste, o ciclo é então repetido. Assim o projeto vai adquirindo as funcionalidades pretendidas.
  21. 21. Red Green Refactor! Test Driven Development
  22. 22. Ciclo Básico do TDD Podemos também resumir os passos do TDD em três itens mais simples. Essa outra abordagem é como se fosse um mantra e reforça pelo menos as 3 coisas mais importantes no TDD. Lembre-se: Red, Green e Refactor!
  23. 23. Ciclo Básico do TDD Podemos também resumir os passos do TDD em três itens mais simples. Essa outra abordagem é como se fosse um mantra e reforça pelo menos as 3 coisas mais importantes no TDD. Lembre-se: Red, Green e Refactor! Pelo que foi visto até agora, isso pode parecer um pouco mais do mesmo, mas não é.
  24. 24. Ciclo Básico do TDD Red Green Refactor
  25. 25. Red Seu teste falha quase que de maneira proposital. Sim. Proposital. Dentro de um teste, chamado TestFulanaDeTal, crie chamada de uma função deTal(), pertencente a um objeto do tipo Fulana. Em PHP: $pessoa = new Fulana(); $resultado = $pessoa->deTal(); A classe Fulana, nem mesmo existe ainda... Mas é assim mesmo. Red
  26. 26. Green Você codifica o mínimo para que seu teste passe. Crie a classe Fulana e implemente o método DeTal(). class Fulana { public function deTal(); } Green
  27. 27. Refactor Após ver o teste ficar verde, você pode melhorar o código. A melhora do código deve ser restrita a atender normas e boas práticas. Se funciona deixe como está. Refactor
  28. 28. TDD com PHP Test Driven Development
  29. 29. PHPUnit É um framework de teste unitário escrito em PHP. Criado por Sebastian Bergman. Embora existam outros frameworks de teste para PHP, basicamente, o PHPUnit tornou-se o padrão. Grandes frameworks PHP, como Zend, Symfony e CakePHP usam o PHPUnit como integrante de suas suítes de testes.
  30. 30. Na prática...
  31. 31. Muito Obrigado! Continua...

×