Your SlideShare is downloading. ×
TDD - Test Driven Development Introdução - PHP
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

TDD - Test Driven Development Introdução - PHP

671
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 …

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

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
671
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TDD Test Driven Developent
  • 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. 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. Por que TDD? Test Driven Development
  • 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. 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. Boas Práticas Test Driven Development
  • 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. Más Práticas Test Driven Development
  • 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. 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. 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. Passos de TDD Test Driven Development
  • 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. 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. 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. 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. 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. 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. Repita Iniciando com outro teste, o ciclo é então repetido. Assim o projeto vai adquirindo as funcionalidades pretendidas.
  • 21. Red Green Refactor! Test Driven Development
  • 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. 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. Ciclo Básico do TDD Red Green Refactor
  • 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. 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. 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. TDD com PHP Test Driven Development
  • 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. Na prática...
  • 31. Muito Obrigado! Continua...