Test-Driven Development - TDD
César Caetano Neto - ccaetano@atech.com.br
● Apresentações e Expectativas
● Coding Dojo
● Era uma vez...
● Introdução ao TDD
● As três Leis e Ciclo de TDD
● Refatora...
Test-Driven Development - TDD
Apresentações e Expectativas
Apresentações e Expectativas
● Nome
● Biografia profissional
● Expectativas...
Testes: Todo mundo sabe, mas nem todos faze...
Test-Driven Development - TDD
Coding Dojo
Coding Dojo
Você se considera um bom programador?
● Em geral, programadores NÃO TREINAM
○ Até mesmo medalhistas olímpicos ...
Coding Dojo
O que é? Para que serve? Benefícios?
Coding Dojo
Dinâmica:
● Pair Programming
● Papéis
○ Sparring (Piloto)
○ Co-Sparring (Co-piloto)
○ Advisors (Conselheiros)
...
Coding Dojo
Qual tal um desafio?
Coding Dojo
Dojo: Lista de Supermercado
Com base em uma lista de compra qualquer e um caminho que você
pode fazer em um su...
Coding Dojo
Dojo: Lista de Supermercado
FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
Coding Dojo
Dojo: Lista de Supermercado
Problema: Imagine uma situação real, onde você vai no supermercado e faz
uma peque...
Coding Dojo
Momento reflexão
● O que foi bom?
● O que pode melhorar?
Título em Arial Bold 24 pontos
Subtítulo em Arial Bold 15 pontos ed vulputate fermentum
Test-Driven Development - TDD
Era ...
● Num projeto “não tão tão distante”...
● Uma equipe “fanfarrona” que decidiu...
● TESTES? → “Quick and Dirty”
● Cobrindo ...
- Moral da história -
Código de teste é tão importante quanto o de produção.
Era uma vez...
Test-Driven Development - TDD
Introdução ao TDD
Introdução ao TDD
● O que é “testar”?
● Conceitos - Tipos de testes
○ Unidade
○ Integração
○ Stress
○ Carga
○ Performance
...
O que é TDD?
O que é TDD?
● O que não é?
● Origem do nome
● Extreme Programming
● Princípios:
○ DRY - “Don’t Repeat Yourself”
○ KISS - ...
Pra quem o TDD é indicado?
● Testes são um meio para um fim
a. Ter CONFIANÇA no código produzido
● Com ele, você vai de:
a. Hesitante → Rápido aprend...
Motivação ao TDD
● Motivações (óbvias para nós, devs)
○ Eliminar MEDO e INCERTEZA
● Outras nem tão óbvias
○ Código mais limpo
○ Melhor desi...
Para o TDD fazer parte do seu dia-a-dia, e perdurar.
Seus testes precisam ser FIRST:
● Fast
● Independent
● Repeatable
● S...
Como saber se escrevi “bons” testes?
● Setup longo?
● Setup duplicado?
● Testes demoram a rodar?
● Testes frágeis?
Introdu...
Porque o TDD funciona?
● Redução de bugs → menor custo
● Menor stress
● Foco
● Melhor relacionamento da equipe
● Sem builds quebrados
● Confiança...
“Não teste o código que não é seu" (Biblioteca de terceiros)
"Se você não testa seu código, ele já se tornou legado"
"Não ...
Test-Driven Development - TDD
As três Leis e o Ciclo TDD
As três Leis do TDD
1. Não escreverás código de produção até que tenhas escrito
um teste que esteja falhando.
2. Não escre...
Ciclo Red-Green-Refactor
RED: Escreva um teste que não funcione, nem mesmo compile
(teste falhando)
Ao escrever o teste fa...
Ciclo Red-Green-Refactor
GREEN: Faça o teste passar da forma mais simples e rápida
possível
● Objetivo → “barra verde” a q...
Ciclo Red-Green-Refactor
REFACTOR: Hora de pagar o débito técnico. Código limpo!
(produção e testes)
● Refatoração sem MED...
Test-Driven Development - TDD
Refatoração, Princípios SOLID e a Lei de Demeter
O que é Refatoração?
Refatoração
Refactoring: “A change made to the internal structure of
software to make it easier to understand and cheaper ...
Por que Refatorar?
Principais motivos:
● Pagar o débito técnico
○ “Code for Tomorrow, design for today.”
● Ajudar a encont...
Refatoração
Algumas técnicas conhecidas:
● Extract Method
● Remove temp with query
● Move method/field
● Extract class
● H...
Refatoração
“Qualquer idiota pode escrever código que um
computador possa entender...”
Refatoração
“...Bons programadores escrevem código que
os seres humanos possam entender.”
Martin Fowler
Refatoração
Padrões de Projeto no TDD:
Padrão Escrita do Teste Refatoração
Command x
Value Object x
Null Object x
Template...
Refatoração
Quando posso apagar meus testes?
● Quando ele não ajuda a aumentar sua confiança
● Quando não ajuda a melhorar...
Princípios SOLID
Importantes princípios de modelagem OO:
● Single Responsibility Principle - SRP
● Open/Closed Principle -...
Single Responsibility Principle
“Uma classe deveria ter um único motivo para mudar”
Single Responsibility Principle
● Coesão
● O que é responsabilidade?
● Equilíbrio
○ Rigidez / Fragilidade
○ Complexidade d...
Single Responsibility Principle
“Um ponto de mudança só é um ponto de mudança se a
mudança realmente ocorrer”
Open/Closed Principle
Quando um simples mudança resulta numa sequência de
outras, temos um programa:
● Frágil
● Rigido
● I...
Open/Closed Principle
“Entidades de Software (classes, módulos, funções, etc.)
devem ser abertas para extensão, mas fechad...
Open/Closed Principle
Quando os requisitos mudam, estende-se um comportamento
adicionando código novo, ao invés de mudar c...
Liskov Substitution Principle
● “Design by Contract”
● Violações (Code smells)
○ Run-Time Type Information (RTTI)
○ Cuidad...
Interface Segregation Principle
“Clientes não deveriam ser forçados a depender de interfaces
que eles não utilizam.”
Interface Segregation Principle
Interface Segregation Principle
Dependency Inversion Principle
Dependency Inversion Principle
Dependency Inversion Principle
“Módulos de alto nível não devem depender de módulos de
baixo nível. Ambos os níveis deveri...
Dependency Inversion Principle
“Abstrações não deveriam depender de detalhes. Detalhes é
que devem depender de abstrações.”
Dependency Inversion Principle
Dependency Inversion Principle
Lei de Demeter
Um método de um objeto deveria invocar somente métodos
dos seguintes tipos de objetos:
● Dele próprio
● Dos...
Lei de Demeter
Onde e quando aplicar a Lei de Demeter?
● Chamadas de métodos (normalmente “get”) encadeadas
● Onde há muit...
Test-Driven Development - TDD
Tech Talk - Ferramentas e Frameworks
Referências eletrônicas
● Apresentação:
http://www.slideshare.net/cesarcneto/treinamento-tdd-atech OU
https://portal.atech...
Referências eletrônicas
● DbUnit
http://dbunit.sourceforge.net/howto.html
● Mockito
http://code.google.com/p/mockito/
● DO...
Referências
● BECK, Kent. Test Driven Development: By Example, Addison-Wesley, 2002.
● EVANS, Benjamin J.; VERBURG, Martij...
Treinamento TDD - Atech
Upcoming SlideShare
Loading in …5
×

Treinamento TDD - Atech

651 views
559 views

Published on

Primeiro treinamento dado sobre Test-Driven Development (TDD) na empresa Atech S/A

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
651
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Treinamento TDD - Atech

  1. 1. Test-Driven Development - TDD César Caetano Neto - ccaetano@atech.com.br
  2. 2. ● Apresentações e Expectativas ● Coding Dojo ● Era uma vez... ● Introdução ao TDD ● As três Leis e Ciclo de TDD ● Refatoração, Princípios SOLID e Lei de Demeter ● Coding Dojo ● Tech Talk - Ferramentas e Frameworks Agenda
  3. 3. Test-Driven Development - TDD Apresentações e Expectativas
  4. 4. Apresentações e Expectativas ● Nome ● Biografia profissional ● Expectativas... Testes: Todo mundo sabe, mas nem todos fazem (direito).
  5. 5. Test-Driven Development - TDD Coding Dojo
  6. 6. Coding Dojo Você se considera um bom programador? ● Em geral, programadores NÃO TREINAM ○ Até mesmo medalhistas olímpicos TREINAM
  7. 7. Coding Dojo O que é? Para que serve? Benefícios?
  8. 8. Coding Dojo Dinâmica: ● Pair Programming ● Papéis ○ Sparring (Piloto) ○ Co-Sparring (Co-piloto) ○ Advisors (Conselheiros) ● Rodadas de X minutos ● Foco no COMO e não na solução
  9. 9. Coding Dojo Qual tal um desafio?
  10. 10. Coding Dojo Dojo: Lista de Supermercado Com base em uma lista de compra qualquer e um caminho que você pode fazer em um supermercado de forma que você irá do primeiro ao último corredor (ver imagem a seguir) sem precisar voltar em lugares que você já passou. FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
  11. 11. Coding Dojo Dojo: Lista de Supermercado FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
  12. 12. Coding Dojo Dojo: Lista de Supermercado Problema: Imagine uma situação real, onde você vai no supermercado e faz uma pequena lista: - desodorante (corredor 5 – posição 3); alho (corredor 1 – posição 9); shampoo (corredor 5 – posição 2); suco (corredor 1 – posição 1); ovo (corredor 1 – posição 8); iogurte (corredor 1 – posição 7); escova dental (corredor 4 – posição 7) Resultado esperado: 1) suco; 2) iogurte; 3) ovo; 4) alho; 5) escova dental; 6) shampoo; 7) desodorante. FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
  13. 13. Coding Dojo Momento reflexão ● O que foi bom? ● O que pode melhorar?
  14. 14. Título em Arial Bold 24 pontos Subtítulo em Arial Bold 15 pontos ed vulputate fermentum Test-Driven Development - TDD Era uma vez...
  15. 15. ● Num projeto “não tão tão distante”... ● Uma equipe “fanfarrona” que decidiu... ● TESTES? → “Quick and Dirty” ● Cobrindo o código de produção, bastaria. ● De versão em versão, estimativas aumentaram... ● ATRASOS? → Culpa dos testes... ● A cada deploy, subia aquele “mal cheiro” Era uma vez...
  16. 16. - Moral da história - Código de teste é tão importante quanto o de produção. Era uma vez...
  17. 17. Test-Driven Development - TDD Introdução ao TDD
  18. 18. Introdução ao TDD ● O que é “testar”? ● Conceitos - Tipos de testes ○ Unidade ○ Integração ○ Stress ○ Carga ○ Performance ○ Outros (Regressão, Mock, Stubs)
  19. 19. O que é TDD?
  20. 20. O que é TDD? ● O que não é? ● Origem do nome ● Extreme Programming ● Princípios: ○ DRY - “Don’t Repeat Yourself” ○ KISS - “Keep It Simple Stupid” ○ YAGNI - “You Ain´t Gonna Need it” “Code for Tomorrow, design for today.”
  21. 21. Pra quem o TDD é indicado?
  22. 22. ● Testes são um meio para um fim a. Ter CONFIANÇA no código produzido ● Com ele, você vai de: a. Hesitante → Rápido aprendizado b. Pouco comunicativo → Melhor comunicação c. Evitar feedback → Aumentar feedbacks d. Mal humorado → Confiante no código (que funciona) Pra quem o TDD é indicado?
  23. 23. Motivação ao TDD
  24. 24. ● Motivações (óbvias para nós, devs) ○ Eliminar MEDO e INCERTEZA ● Outras nem tão óbvias ○ Código mais limpo ○ Melhor design ○ Maior flexibilidade ○ Feedback rápido Motivação ao TDD
  25. 25. Para o TDD fazer parte do seu dia-a-dia, e perdurar. Seus testes precisam ser FIRST: ● Fast ● Independent ● Repeatable ● Self-Validating ● Timely Introdução ao TDD
  26. 26. Como saber se escrevi “bons” testes? ● Setup longo? ● Setup duplicado? ● Testes demoram a rodar? ● Testes frágeis? Introdução ao TDD
  27. 27. Porque o TDD funciona?
  28. 28. ● Redução de bugs → menor custo ● Menor stress ● Foco ● Melhor relacionamento da equipe ● Sem builds quebrados ● Confiança interna e externa ● Nova versão → mais funcionalidades (e menos bugs) Porque o TDD funciona?
  29. 29. “Não teste o código que não é seu" (Biblioteca de terceiros) "Se você não testa seu código, ele já se tornou legado" "Não re-escreva nada que você não tenha um teste" Algumas citações sobre TDD
  30. 30. Test-Driven Development - TDD As três Leis e o Ciclo TDD
  31. 31. As três Leis do TDD 1. Não escreverás código de produção até que tenhas escrito um teste que esteja falhando. 2. Não escreverás mais que o suficiente para falhar um teste de unidade, e não compilar é falhar. 3. Não escreverás mais código que o suficiente para passar o teste falho.
  32. 32. Ciclo Red-Green-Refactor RED: Escreva um teste que não funcione, nem mesmo compile (teste falhando) Ao escrever o teste falho, você decidiu: ● De “quem” é a funcionalidade? ● Qual nomenclatura (DSL)? ● Qual a resposta certa? ● Quais outros cenários/testes relacionados?
  33. 33. Ciclo Red-Green-Refactor GREEN: Faça o teste passar da forma mais simples e rápida possível ● Objetivo → “barra verde” a qualquer custo ● Foco na resolução do problema/cenário ● Feedback rápido
  34. 34. Ciclo Red-Green-Refactor REFACTOR: Hora de pagar o débito técnico. Código limpo! (produção e testes) ● Refatoração sem MEDO ● Princípios SOLID ● Lei de Demeter ● Design Patterns
  35. 35. Test-Driven Development - TDD Refatoração, Princípios SOLID e a Lei de Demeter
  36. 36. O que é Refatoração?
  37. 37. Refatoração Refactoring: “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” [FOWLER, 1999] Refactor: “To restructure software by applying a series of refactorings without changing its observable behavior.” [FOWLER, 1999]
  38. 38. Por que Refatorar? Principais motivos: ● Pagar o débito técnico ○ “Code for Tomorrow, design for today.” ● Ajudar a encontrar “bugs” ● Tornar futuras mudanças “baratas” ● Legibilidade ● Legibilidade ● Legibilidade
  39. 39. Refatoração Algumas técnicas conhecidas: ● Extract Method ● Remove temp with query ● Move method/field ● Extract class ● Hide delegate (Lei de Demeter) ● Remove middle man (Oposto de hide delegate) ● Remove data value with object ● ...
  40. 40. Refatoração “Qualquer idiota pode escrever código que um computador possa entender...”
  41. 41. Refatoração “...Bons programadores escrevem código que os seres humanos possam entender.” Martin Fowler
  42. 42. Refatoração Padrões de Projeto no TDD: Padrão Escrita do Teste Refatoração Command x Value Object x Null Object x Template Method x Factory Method x x Imposter x x Composite x x Collecting Parameter x x
  43. 43. Refatoração Quando posso apagar meus testes? ● Quando ele não ajuda a aumentar sua confiança ● Quando não ajuda a melhorar a comunicação
  44. 44. Princípios SOLID Importantes princípios de modelagem OO: ● Single Responsibility Principle - SRP ● Open/Closed Principle - OCP ● Liskov Substitution Principle - LSP ● Interface Segregation Principle - ISP ● Dependency Inversion Principle - DIP
  45. 45. Single Responsibility Principle “Uma classe deveria ter um único motivo para mudar”
  46. 46. Single Responsibility Principle ● Coesão ● O que é responsabilidade? ● Equilíbrio ○ Rigidez / Fragilidade ○ Complexidade desnecessária
  47. 47. Single Responsibility Principle “Um ponto de mudança só é um ponto de mudança se a mudança realmente ocorrer”
  48. 48. Open/Closed Principle Quando um simples mudança resulta numa sequência de outras, temos um programa: ● Frágil ● Rigido ● Imprevisível ● Sem re-uso
  49. 49. Open/Closed Principle “Entidades de Software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para alteração”
  50. 50. Open/Closed Principle Quando os requisitos mudam, estende-se um comportamento adicionando código novo, ao invés de mudar código antigo que funciona. Como? → Abstração
  51. 51. Liskov Substitution Principle ● “Design by Contract” ● Violações (Code smells) ○ Run-Time Type Information (RTTI) ○ Cuidado com as relações “É um” ● O princípio é sobre: Comportamento ○ Pré-condições ○ Pós-condições
  52. 52. Interface Segregation Principle “Clientes não deveriam ser forçados a depender de interfaces que eles não utilizam.”
  53. 53. Interface Segregation Principle
  54. 54. Interface Segregation Principle
  55. 55. Dependency Inversion Principle
  56. 56. Dependency Inversion Principle
  57. 57. Dependency Inversion Principle “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos os níveis deveriam depender de abstrações.”
  58. 58. Dependency Inversion Principle “Abstrações não deveriam depender de detalhes. Detalhes é que devem depender de abstrações.”
  59. 59. Dependency Inversion Principle
  60. 60. Dependency Inversion Principle
  61. 61. Lei de Demeter Um método de um objeto deveria invocar somente métodos dos seguintes tipos de objetos: ● Dele próprio ● Dos pâmetros dele ● De qualquer objeto criado ou instanciado ● Seus objetos/componentes diretos (1 nível)
  62. 62. Lei de Demeter Onde e quando aplicar a Lei de Demeter? ● Chamadas de métodos (normalmente “get”) encadeadas ● Onde há muitos objetos temporários ● Ao importar muitas classes ○ Exemplo: import java.awt.*; ● Design Patterns (GoF)
  63. 63. Test-Driven Development - TDD Tech Talk - Ferramentas e Frameworks
  64. 64. Referências eletrônicas ● Apresentação: http://www.slideshare.net/cesarcneto/treinamento-tdd-atech OU https://portal.atech.com. br/share/page/site/treinamentos/documentlibrary ● Código fonte no GitHub: http://github.com/cesarcneto/tdd- course ● Design Patterns e Refatoração: http://sourcemaking. com/refactoring ● Blog do Aniche: http://www.aniche.com.br/tag/tdd/ ● Princípios de OO http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
  65. 65. Referências eletrônicas ● DbUnit http://dbunit.sourceforge.net/howto.html ● Mockito http://code.google.com/p/mockito/ ● DOJOs http://dojopuzzles.com/
  66. 66. Referências ● BECK, Kent. Test Driven Development: By Example, Addison-Wesley, 2002. ● EVANS, Benjamin J.; VERBURG, Martijn. The Well Grounded Java Developer, Manning, 2013. ● FOWLER, Martin. Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999. ● FREEMAN, Steve; PRYCE, Nat. Growing Object-Oriented Software Guided by Tests, Addison-Wesley, 2009. ● HUNT, Andrew; THOMAS, David. The Pragmatic Programmer, Addison- Wesley, 1999. ● MARTIN, Robert C. Clean Code - A Handbook of Agile Software Craftsmanship, Prentice Hall, 2009. ● McCONNELL, Steve. Code Complete - A Practical Handbook of Software Construction, 2nd Edition, Microsoft Press, 2004. ● MYERS, Glenford J. The Art of Software Testing, John Wiley & Sons, Inc., 2004.

×