Tweet
Tweet

Slide 1

Slide 1 text

Test-driven Development Felipe Elias Philipp @ W3BOX 15/01/2010 Friday, January 29, 2010

Slide 2

Slide 2 text

O dia a dia de um desenvolvedor Friday, January 29, 2010

Slide 3

Slide 3 text

Pensamentos comuns (e errados) sobre testes Friday, January 29, 2010

Slide 4

Slide 4 text

Pensamentos comuns (e errados) sobre testes • Eu sou desenvolvedor, não sou testador. Friday, January 29, 2010

Slide 5

Slide 5 text

Pensamentos comuns (e errados) sobre testes • Eu sou desenvolvedor, não sou testador. • Vou deixar alguém que conheça as regras de negócio testar. Friday, January 29, 2010

Slide 6

Slide 6 text

Pensamentos comuns (e errados) sobre testes • Eu sou desenvolvedor, não sou testador. • Vou deixar alguém que conheça as regras de negócio testar. • É melhor deixar outra pessoa testar. Friday, January 29, 2010

Slide 7

Slide 7 text

Pensamentos comuns (e errados) sobre testes • Eu sou desenvolvedor, não sou testador. • Vou deixar alguém que conheça as regras de negócio testar. • É melhor deixar outra pessoa testar. • Não tenho tempo para testar. Friday, January 29, 2010

Slide 8

Slide 8 text

Quem deve testar? Quem é responsável pelos testes? Friday, January 29, 2010

Slide 9

Slide 9 text

Por que o desenvolvedor deve testar? Friday, January 29, 2010

Slide 10

Slide 10 text

Como testar? Friday, January 29, 2010

Slide 11

Slide 11 text

TDD - Test-driven Development Friday, January 29, 2010

Slide 12

Slide 12 text

“É uma técnica de desenvolvimento de software em que se desenvolve em pequenas iterações, onde primeiro se escreve o teste e depois o código. Cada iteração deve começar com um teste que falhe, e terminar com todos os testes passando” Friday, January 29, 2010

Slide 13

Slide 13 text

• O programador escreve um teste que falhe. O ciclo de TDD Friday, January 29, 2010

Slide 14

Slide 14 text

• O programador escreve um teste que falhe. • O programador escreve o código mais simples possível para o teste passar. O ciclo de TDD Friday, January 29, 2010

Slide 15

Slide 15 text

• O programador escreve um teste que falhe. • O programador escreve o código mais simples possível para o teste passar. • Com todos os testes passando, refatora-se o código se necessário. O ciclo de TDD Friday, January 29, 2010

Slide 16

Slide 16 text

• O programador escreve um teste que falhe. • O programador escreve o código mais simples possível para o teste passar. • Com todos os testes passando, refatora-se o código se necessário. • Ciclo se repete. O ciclo de TDD Friday, January 29, 2010

Slide 17

Slide 17 text

Quais as vantagens do TDD? Friday, January 29, 2010

Slide 18

Slide 18 text

Mais segurança e confiança no código Se alguém introduzir um bug, o teste falhará. Friday, January 29, 2010

Slide 19

Slide 19 text

Desacoplamento entre os componentes Sem aquela história: “mexe de um lado, estraga de outro” Friday, January 29, 2010

Slide 20

Slide 20 text

Melhor qualidade do código Facilidade na refatoração Friday, January 29, 2010

Slide 21

Slide 21 text

Os testes servem como especificação e são executáveis! Friday, January 29, 2010

Slide 22

Slide 22 text

TDD não é... • ... teste caixa preta. Friday, January 29, 2010

Slide 23

Slide 23 text

TDD não é... • ... teste caixa preta. • ... teste de aceitação. Friday, January 29, 2010

Slide 24

Slide 24 text

TDD não é... • ... teste caixa preta. • ... teste de aceitação. • ... perda de tempo. Friday, January 29, 2010

Slide 25

Slide 25 text

TDD não é... • ... teste caixa preta. • ... teste de aceitação. • ... perda de tempo. • ... bala de prata. Friday, January 29, 2010

Slide 26

Slide 26 text

Algumas dicas Friday, January 29, 2010

Slide 27

Slide 27 text

Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. Friday, January 29, 2010

Slide 28

Slide 28 text

Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. • Escreva um teste legível. Friday, January 29, 2010

Slide 29

Slide 29 text

Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. • Escreva um teste legível. • Crie testes simples de resolver. Friday, January 29, 2010

Slide 30

Slide 30 text

Algumas dicas • Faça um brainstorm antes para pensar nos testes possíveis. • Escreva um teste legível. • Crie testes simples de resolver. • Use dados reais! Friday, January 29, 2010

Slide 31

Slide 31 text

Alguns mantras Friday, January 29, 2010

Slide 32

Slide 32 text

Alguns mantras • Não tente resolver todos os problemas de uma vez. Friday, January 29, 2010

Slide 33

Slide 33 text

Alguns mantras • Não tente resolver todos os problemas de uma vez. • Não vá para o próximo teste quando você ainda está resolvendo o atual. Friday, January 29, 2010

Slide 34

Slide 34 text

Alguns mantras • Não tente resolver todos os problemas de uma vez. • Não vá para o próximo teste quando você ainda está resolvendo o atual. • Se você precisa de mais funcionalidades, exponha-as em um teste. Friday, January 29, 2010

Slide 35

Slide 35 text

Alguns mantras • Não tente resolver todos os problemas de uma vez. • Não vá para o próximo teste quando você ainda está resolvendo o atual. • Se você precisa de mais funcionalidades, exponha-as em um teste. • Se você encontrar um bug, exponha-o em um teste. Friday, January 29, 2010

Slide 36

Slide 36 text

Alguns mantras • Não tente resolver todos os problemas de uma vez. • Não vá para o próximo teste quando você ainda está resolvendo o atual. • Se você precisa de mais funcionalidades, exponha-as em um teste. • Se você encontrar um bug, exponha-o em um teste. • Não refatore até os testes estarem passando (verde). Friday, January 29, 2010

Slide 37

Slide 37 text

Perguntas? Friday, January 29, 2010