Carregado porthiagobapt
1,123 visualizações

TDD para "meros mortais"

O documento discute a aplicação do Test-Driven Development (TDD) na vida real, destacando a experiência de um desenvolvedor que se considera um 'mero mortal'. Ele enfatiza a necessidade de aprendizado contínuo, a importância de um design de código robusto e como os princípios de TDD ajudam a evitar problemas comuns enfrentados em projetos de software. Além disso, apresenta exemplos práticos e lições aprendidas ao longo do processo de desenvolvimento utilizando TDD.

Incorporar apresentação

Baixado 18 vezes
1 / 140
2 / 140
3 / 140
4 / 140
5 / 140
6 / 140
7 / 140
8 / 140
9 / 140
10 / 140
11 / 140
12 / 140
13 / 140
14 / 140
15 / 140
16 / 140
17 / 140
18 / 140
19 / 140
20 / 140
21 / 140
22 / 140
23 / 140
24 / 140
25 / 140
26 / 140
27 / 140
28 / 140
29 / 140
30 / 140
31 / 140
32 / 140
33 / 140
34 / 140
35 / 140
36 / 140
37 / 140
38 / 140
39 / 140
40 / 140
41 / 140
42 / 140
43 / 140
44 / 140
45 / 140
46 / 140
47 / 140
48 / 140
49 / 140
50 / 140
51 / 140
52 / 140
53 / 140
54 / 140
55 / 140
56 / 140
57 / 140
58 / 140
59 / 140
60 / 140
61 / 140
62 / 140
63 / 140
64 / 140
65 / 140
66 / 140
67 / 140
68 / 140
69 / 140
70 / 140
71 / 140
72 / 140
73 / 140
74 / 140
75 / 140
76 / 140
77 / 140
78 / 140
79 / 140
80 / 140
81 / 140
82 / 140
83 / 140
84 / 140
85 / 140
86 / 140
87 / 140
88 / 140
89 / 140
90 / 140
91 / 140
92 / 140
93 / 140
94 / 140
95 / 140
96 / 140
97 / 140
98 / 140
99 / 140
100 / 140
101 / 140
102 / 140
103 / 140
104 / 140
105 / 140
106 / 140
107 / 140
108 / 140
109 / 140
110 / 140
111 / 140
112 / 140
113 / 140
114 / 140
115 / 140
116 / 140
117 / 140
118 / 140
119 / 140
120 / 140
121 / 140
122 / 140
123 / 140
124 / 140
125 / 140
126 / 140
127 / 140
128 / 140
129 / 140
130 / 140
131 / 140
132 / 140
133 / 140
134 / 140
135 / 140
136 / 140
137 / 140
138 / 140
139 / 140
140 / 140
TDD para “meros mortais” Porque a vida real é mais que Fibonacci!
Quem sou eu? Thiago Baptista Desenvolvedor há uns 3 anos (principalmente Java) Entusiasta do Software Livre e do Movimento Ágil Tarado por Computação e estudar novas tecnologias...
Quem sou eu? ...UM “MERO MORTAL”!!! Não sei nem 40% do que ACHO que sei Não sei nem 30% do que eu DEVERIA saber Vivo no “mundo real”
Como assim, “mundo real”? Agilidade é (ainda) desconhecida Empresas são “fábricas de software” Relação cliente-empresa é conflituosa Prazos estouram, retrabalho, código “macarrônico” etc. Maioria dos projetos é manutenção de código legado
Desenvolvedores do “mundo real” Não têm larga experiência Se concentram em uma tecnologia Foram educados em uma metodologia de trabalho Na faculdade vivem um mundo totalmente distante do mercado de trabalho (Swing?? Dicionário de dados??? UML é “novidade”?!?)
O trabalho do desenvolvedor na “vida real” Empresas que há muitos anos trabalham da mesma forma Gerentes e chefes que desconhecem o ofício Ou, quando conhecem, estão MUITO desatualizados Num constante clima de correria e prazos estourados Sem tempo ou recursos para se atualizar Sem incentivo para se atualizar
Dialética do desenvolvimento de software Tese: de um lado, essa “vida real” Antítese: do outro, novas e muito melhores técnicas, metodologias e tecnologias Síntese: ???
Desenvolvedor “ágil” hoje: meu caso Li e estudei bastante sobre isso Vi na prática acontecer e dar certo Defendo e procuro aplicar isso Porém...
Desenvolvedor “ágil” hoje: meu caso ...SOU UM MERO MORTAL!!! Conheço bem a teoria, mas tenho pouca experiência prática Portanto, sei muito menos do que eu ACHO que sei Tive pouquíssimas oportunidades de colocar em prática
TDD para “meros mortais” Estudo de caso: um “mero mortal” aplicando a teoria do TDD na prática!
Revisando a teoria...
Desenvolvimento (ou design) guiado por testes Escreve-se um teste primeiro, e só depois o código “real” Código “real” é sempre fruto de se fazer um teste escrito previamente passar Test-Driven Development/Design
TDD em essência Segundo Kent Beck, “autor” da técinca: Escreva um teste automatizado que falhe antes de escrever qualquer outro código Escreva um código para fazer esse teste passar Remova a duplicação
TDD em essência Segundo Kent Beck, “autor” da técinca: Escreva um teste automatizado que falhe antes de escrever qualquer outro código [VERMELHO] Escreva um código para fazer esse teste passar [VERDE] Remova a duplicação [REFATORAR] ...repetir o processo...
Conceitos importantes Só pode haver código “real” se houver antes um teste que falhe Deve-se avançar com “passinhos de bebê” (baby steps) Só se adiciona um novo teste que falhe após todos os outros testes estarem “verdes”
Baby steps Faz-se o mínimo necessário para o teste ficar “verde” Após o “verde”, refatora-se para eliminar a redundância Cria-se um novo teste para “quebrar” novamente Faz-se o mínimo necessário para ambos os testes passarem Refatora-se de novo Repete-se o processo até ter código “real” funcionando “de verdade”
Clássico exemplo: multiplicar por 2 Funcionalidade: um método que receba um inteiro como argumento e retorne o produto deste por 2 Exemplos: multiplicar(5) == 10 multiplicar(13) == 26 multiplicar(0) == 0
Clássico exemplo: multiplicar por 2 Primeiro passo: um teste que falha
Clássico exemplo: multiplicar por 2 Segundo passo: implementar o mínimo absoluto pro teste passar
Clássico exemplo: multiplicar por 2 Terceiro passo: novo teste que falha e “quebra” o código
Clássico exemplo: multiplicar por 2 Quarto passo: implementar, novamente, o mínimo para os dois testes passarem
Clássico exemplo: multiplicar por 2 Quinto passo: refatorar para eliminar a redundância
Clássico exemplo: multiplicar por 2 Enésimo passo: repetir até ter a segurança para implementar o código “de verdade”, de produção
Conclusões e benefícios TDD é como a rede de proteção dos malabaristas no circo De quebra, ainda te dá uma cobertura de testes Garante que o código faça o mínimo necessário Manter esse código: mel na chupeta! É só continuar com o processo do TDD de onde parou Garante a aprendizagem do código
Aprendizagem do código??
Desenvolvimento de software NÃO É MANUFATURA!!!
Na manufatura... Você sabe de antemão o resultado que quer (você tem o “molde”) O processo de construção é determinístico Para cada resultado esperado, um processo determinado f(x) = y O processo de construção é conhecido previamente O processo de construção pode ser replicado
...agora, digamos, na arte...
Desenvolver software é traduzir CONHECIMENTOS DE NEGÓCIO para ALGORÍTMOS COMPUTACIONAIS
Como??
VOCÊ NÃO SABE!!!!
Você não sabe: Sobre o negócio, tão bem quanto o cliente Sobre a real necessidade de um requisito na “hora H” Se o cliente sabe o que quer ou se você o entendeu direito Se no futuro os requisitos mudarão Se você está traduzindo o conhecimento direito Se você sabe desenvolver software
Lição número 1 TDD é sobre o aprendizado do código
Aprendizado?? Mas eu sei multiplicar um número por 2...
TDD na “vida real” “Multiplicar por 2”, Fibonacci, Fatorial etc. são exemplos conceituais A “vida real” é muito mais complexa CRUDs que lidam com persistência Aplicações web que lidam com a camada HTTP Threads, computação assíncrona etc.
Estudo de caso: cliente para o WebPagetest
Estudo de caso: cliente para o WebPagetest http://www.webpagetest.org Aplicação web para testar desempenho de sites Fornece uma API REST, mediante inscrição (gratuita) https://sites.google.com/a/webpagetest.org/docs/advanced- features/webpagetest-restful-apis Gera relatórios na web, via XML ou JSON
O desafio: Cliente de linha de comando (shell) para o WebPagetest Para rodar de tempos em tempos (cron) Deve iniciar um teste para um site específico Deve aguardar o teste terminar e saber quando isso acontecer Deve obter o relatório do teste e exibir os dados conforme requerido
Os obstáculos: API com número reduzido de chamadas permitidas Só 200 testes num período de 24hs Ter que usar a camada HTTP Trabalhar com XMLs (API JSON muito limitada na época) Trabalhar com a linha de comando Para chamar a aplicação e iniciar o teste Para exibir os resultados do teste Salvar resultados no sistema de arquivos (em logs)
As ferramentas: Plataforma Java Groovy API HTTP nativa API de XML nativa API de testes nativa API nativa para trabalhar com a linha de comando (Groovy CLI) TDD
Como fazer isso??
TDD me ensinou!
Tá, mas... por onde começar??
Aplicando o TDD Minha principal dúvida: por onde começar um projeto da “vida real” Qual classe? Qual caso de uso ou história do usuário? Qual método? Qual funcionalidade? Se uso um framework, devo começar o testando também? Maior “defeito” do ensino do TDD - onde se começa
E por falar em “começos”...
Testes “tradicionais” e TDD “Teste”, tradicionalmente, faz parte da linguagem do controle de qualidade (“Quality Assurance” - QA) Testa-se para saber se algo que já existe se conforma a padrões esperados de comportamento e qualidade Todo um mundo de metodologias, técnicas, certificações etc. Todo um linguajar próprio: Teste de unidade, de integração, de regressão, de aceitação Teste “caixa-preta”, “caixa-branca”, “caixa-cinza” etc.
Testes “tradicionais” e TDD O profissional de QA planeja a execução dos testes conforme os requisitos, testa e, então, gera seus artefatos
TDD não é sobre QA!
QA é muito importante, mas não é disso que estamos falando...
TDD e “tipos de teste” O linguajar sobre testes, em TDD, quer dizer coisas diferentes do que quer dizer em QA Teste de unidade geralmente se refere à “testar classes” Teste de integração/aceitação geralmente se refere a testar funcionalidades
Então, por que o “T”? Na verdade, o “teste” representa uma expectativa, um propósito que o código deve atender O propósito desse método é multiplicar a entarda por 2 O propósito dessa classe é se conectar a um SGBD O propósito desse módulo é ser um adaptador de uma API externa para nossa Etc.
Sendo assim, é realmente um “T”? Um propósito é o reflexo de uma necessidade que o código deve atender Fazemos escolhas de projeto (design) do código para atender essa necessidade É um “teste” na medida em que garante que o projeto do nosso código atenda a essa necessidade
Portanto, não é sobre “teste”...
...é sobre projeto!
Lição número 2 TDD é sobre o projeto, sobre o design do código
Estamos destacando a palavra errada...
TEST Driven Design
Test Driven DESIGN
Sobre por onde começar Segundo a teoria: de “cima para baixo” Do ponto de vista do usuário Com um “teste de aceitação” que representa uma funcionalidade Teste que só passaria com a integração de todo o sistema Ou seja: do HTML à JPA, passando pelo modelo
Mas e se não der pra ser assim?
Começe de onde der pra começar!!!
Lição número 3 Quando em dúvida, começe o TDD de onde você se sentir mais confortável
Começando pelo mais confortável Pelo elemento mais básico do código que resolva o problema em questão A classe mais óbvia O método mais fácil de se fazer O módulo com menos dependências
Exemplo prático: cliente WebPagetest O começo mais óbvio de qualquer código... é ele existir! Deve haver um objeto que represente o sistema que queremos construir - o WPTClient
Exemplo prático: cliente WebPagetest Próximo passo: deve fazer o óbvio! Nosso objeto deve ser capaz de executar sua funcionalidade mais básica.
Opa! Redundância no código do teste!!
O segundo teste claramente “cobre” o propósito do primeiro - garantir que exista um objeto WPTClient. Portanto...
...elimina-se a redundância!
Opa! O código do teste também evoluiu!
Lição número 4 O código do “teste” também “é código” e, portanto, também evolui
Teste também “é código”! O código do teste também progride conforme o aprendizado do código progride “É código”, portanto: atenção às boas práticas! Código limpo Eliminar “bad smells” OO “de verdade”
WPTClient e evolução do código Com o tempo, a classe WPTClient passou a ter muitas responsabilidades: Existir Iniciar o teste Se conectar à camada HTTP Acessar a URI correta e mandar a requisição correta à API do WebPagetest...
WPTClient: e os métodos “internos” Dúvida muito comum: como fazer TDD de métodos privados? Ou de algoritmos internos a um método void? Resposta geral: testa-se o estado que o método “interno” altera Se o resultado do cálculo matemático está correto Se o HTML está corretamente formatado Se a lista tem o número de membros esperado
WPTClient inicia teste numa URL WTPClient deve iniciar um teste numa URL válida WPTClient não deve iniciar um teste numa URL inválida
WPTClient inicia teste numa URL Supondo que estejamos prontos pra criar a implementação “de verdade”, isso implica em: Acessar a API HTTP do Groovy “de verdade” Preparar a chamada à API “de verdade”
WPTClient inicia teste numa URL Opa! Se conectar à web de verdade? A API tem um número limitado de chamadas permitidas Se trata da integração com uma parte “externa” a essa “unidade” E se no dia a Internet cair? E se der errado, como vou saber que é problema do meu código, e não da infraestrutura de redes?
Evoluindo o código: novas classes Solução: refatorar o método iniciarTeste() para usar novos objetos Transferir essas responsabilidades para os devidos objetos Com isso: Testa-se os objetos, e não um método “fechado” Elimina-se o acoplamento da classe WPTClient
Fomos disso...
...para isso...
...e também ganhamos isso!
Lição número 5 TDD é sobre projeto de código evolutivo, que cresce e se desenvolve como um organismo vivo
Código evolutivo TDD permite cultivar o código, como uma planta que cresce Seu “DNA” - os requisitos, o propósito a qual o código serve Novas classes surgem como novas células Desenvolvimento não linear do código Novas classes surgem conforme a necessidade Novos testes surgem conforme a necessidade
O código “fala” contigo, dizendo pra onde você deve ir!
Evolução do código: onde ocorre? Só pode haver evolução se há testes (propósitos) sendo atendidos É fruto de atender melhor a esses propósitos Assim, ocorre com a refatoração Portanto, a etapa da refatoração não pode ser negligenciada!
Lição número 6 É impossível o código evoluir sem haver a refatoração
Refatoração e evolução do código É onde os padrões de projeto OO são postos em prática É onde se identifica a necesidade de se evoluir o código É onde se descobre os “ganchos” para isso acontecer
Exemplo: motor de videojogo Classe WalkerGameObject, desenvolvida com TDD Testes passando (VERDE) If...else...if...else...if... OO mandou lembranças...
Exemplo: refatorando para padrões
E por falar em qualidade do código...
Voltando aos métodos privados... Métodos privados ou com “algoritmos internos” não são facilmente testáveis
Testando essa classe... Como eu sei se o Produto recebido está ou não nulo? Como eu sei que getNotNullProperties() só retornou propriedades não nulas? Como eu sei se consegui criar direito um DataSourceConnection? Como eu sei se o método filter() realmente filtrou? Como eu sei se o método replaceProperties() funcionou?
Epa! E não é só isso!
A classe ProductParser... Tem mais de uma responsabilidade Assegurar que o Porduto não seja nulo Criar e gerenciar uma classe que faz conexão com o sistema de arquivos Gerenciar e alterar as propriedades do Produto Está altissimamente acoplada às suas dependências
Ou seja...
É difícil de testar... E ...é mal escrita (alto acoplamento, várias responsabilidades...)
...coincidência?
NÃO!!!
É consequência! O principal problema da “testabilidade” do código é que ele é mal projetado Segundo Michael Feathers, alto acoplamento é a maior dor de cabeça de se lidar com código legado Portanto: código projetado pra “ser testável” é código bem projetado!
Lição número 7 TDD garante o melhor projeto de código; se um código não é “testável”, ele está errado
TDD e qualidade de código Não lute contra a dificuldade de se criar um teste! Provavelmente, significa que há uma forma melhor de se projetar o código Exemplo: testar a existência do loop principal de um videojogo
WPTClient e qualidade de código Exemplo: trabalhar com o XML de resposta do teste
Possível solução: API de XML do Groovy
Porém... E se essa API não funcionar para o que eu quero? E se a API mudar no futuro? E se o XML de resposta mudar no futuro? O código ficara acoplado a essa API!
O que diz o TDD mesmo...? Código “real” é sempre fruto de se fazer um teste escrito previamente passar
Portanto... Criemos o teste para haver a classe Resposta!
Ao seguirmos o TDD “à risca”... Ganhamos a classe Resposta Desacoplamos nossa implementação das duas APIs (de XML e do WebPagetest) Garantimos a cobertura de testes Tornamos a futura manutenção dessa classe um “passeio no parque”
Devemos seguir TDD “à risca” porque...
Lição número 9 TDD é um processo contínuo que, pra funcionar, não deve ser interrompido
Se você para de usar TDD numa parte do código, o sistema todo pode ruir!
Afinal, TDD é sobre DESIGN, não sobre testes!
WPTClient e o código “macarrônico” Por pura negligência, fiz a parte da linha de comando sem TDD... É a parte mais horrenda do código Mantê-la será um pesadelo para a heroina ou o herói que se habilitar...
Resultado: Erro na hora de imprimir no shell o resultado dos testes Erro ao salvar o arquivo dos testes no sistema de arquivos Gastei horas pra resolver a questão dos parâmetros da linha de comando Percebi que li a API errada e tive que refazer umas 60 linhas de código!
TDD como processo contínuo Ou o código é fruto da certeza de que ele atende um propósito, ou ele é código incerto Segundo Michael Feathers: código legado é todo código sem teste! Mesmo o código que você acabou de escrever
Lição número 10 Nunca, jamais subestime a necessidade dos baby steps
WPTClient: herança da classe Resposta Na API do WebPagetest, há um único XML de resposta, porém ela pode ser: De falha ao iniciar o teste De teste iniciado De teste em andamento De teste concluido O relatório em si do teste
WPTClient: a classe Resposta Desenvolvida por TDD Também com o “if-else hell”...
Jogando o TDD pro espaço... Sem seguir o processo de baby steps, criei toda uma hierarquia de classes “Resposta” Interface “Resposta” Classe “TesteIniciado” Classe “TestePendente” Etc.
SEM escrever testes primeiro!
...resultado?
O sistema inteiro “quebrou”!!
Passinhos de bebê... jupteriano!
Resultado? Tive que desfazer todas as alterações Tive que garantir que todos os testes continuassem passando Aprendi a lição
Mas... e a qualidade do código? E as “boas práticas”?
Lição número 11 TDD garante a qualidade funcional do código, e não necessariamente a “estética”
TDD sem “purismos” Código “dentro dos padrões” é consequência no TDD, não o objetivo primordial Padrões de projeto, por si só, não garantem um código funcional Se no futuro for necessário, o TDD garante a “beleza” do código - refatoração
TDD e integração Como fazer TDD em sistemas com integrações/dependências externas? CRUDs com JPA Aplicações web Teste unitário? De integração? De aceitação?
TEST Driven Design...?
Test Driven DESIGN!
A “integração” é um propósito em si do código!
Lição número 12 Integração de sistemas/módulos em TDD é função do projeto do código, e não do “tipo” de teste
TDD e integração A responsabilidade de uma classe é um propósito: A classe FormatadorDeString formata strings... A classe ProdutoComparator compara produtos... A classe URLValidator valida URLs... E a integração com um sistema/módulo externo também é um propósito!
WPTClient e integração Exemplo prático de integração: WPTClient e requisições HTTP Se conectar “de verdade” à web é um requisito... ...portanto um propósito... ...portanto deve ser projetada guiando-se em testes.
WPTClient e integração Duas coisas distintas a se testar: Se a classe WPTClient é capaz de se conectar à camada HTTP - a “unidade” Se a integração do nosso sistema com o HTTP funciona “de verdade” - a “integração” De onde surge essa distinção? Dos testes.
WPTClient e integração Testando a “unidade”, obtivemos isso:
WPTClient e integração Para testar a “unidade”, fizemos isso:
WPTClient e integração E, para testar a “integração”, obtivemos isso:
E depois dessa experiência?
Continuo um “mero mortal”... Como fazer TDD em código legado? TDD em equipe: como evitar “quebrar” o processo? TDD “avançado”: threads, computação assíncrona etc. TDD vs BDD
Bibliografia BECK, Kent. “TDD by Example” FREEMAN, Steve & PRICE, Nat. “Growing OO Software Guided by Tests” FEATHERS, Michael. “Working Effectively with Legacy Code” KOSKELA, Lasse. “Test Driven: TDD and Acceptance TDD for Java Developers”
Obrigado! thiagobapt@gmail.com blog.thiagobaptista.com (fora do ar...) github.com/thiagobaptista

Mais conteúdo relacionado

PPTX
TDD: Técnicas, Benefícios e Limitação
porIcaro Camelo
 
PDF
Introdução ao TDD (Test-Driven Development) - #guma10anos
porDionatan default
 
PDF
Test Driven Development (TDD) para seres humanos.
porRômulo Augusto Santos
 
PDF
Tdd na veia
porBruno Maomeh
 
PDF
TDD: A Essência do Mantra
porDionatan default
 
PPTX
TDD
porJoão Victorino
 
PPTX
Introdução a TDD
porDaniel Sobral
 
PDF
TDD - Pós Graduação em Engenharia de Software Ágil
porBruno Eustáquio
 
TDD: Técnicas, Benefícios e Limitação
porIcaro Camelo
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
porDionatan default
 
Test Driven Development (TDD) para seres humanos.
porRômulo Augusto Santos
 
Tdd na veia
porBruno Maomeh
 
TDD: A Essência do Mantra
porDionatan default
 
TDD
porJoão Victorino
 
Introdução a TDD
porDaniel Sobral
 
TDD - Pós Graduação em Engenharia de Software Ágil
porBruno Eustáquio
 

Mais procurados

PDF
Automatizando testes em 4 passos
porHélio Medeiros
 
PDF
Test Driven Development - Em busca de feedback util e concreto
porHélio Medeiros
 
PPT
Apresentacao tdc 2012
porJorge Oleques
 
PPTX
Como TDD pode influenciar na construção do seu Produto?
porRaphael Paiva
 
PPT
Introdução ao TDD
porThiago Faria de Andrade
 
PDF
TDD com Python
porOsvaldo Santana Neto
 
PPTX
Testes e mocks: Em Visual Studio com .NET
porAlessandro Binhara
 
PDF
Desenvolvimento orientado a testes
porCarlos Santana
 
PDF
Coding Dojo - Funcionamento
porthiagodp
 
PDF
O programador pragmático
poredgarddavidson.com
 
PPT
Seja Um Programador Pragmatico
porLeonardo Fernandes
 
PDF
O Programador Pragmático
porTadeu Marinho
 
PDF
TDD para Java EE
porDairton Bassi
 
PPT
Programação Pragmática
porelliando dias
 
PDF
Multidisciplinaridade - Desconstruindo especialistas e construindo times
porHélio Medeiros
 
PDF
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
porDeveloper Academy
 
PDF
Boas práticas no desenvolvimento de software
porCarlos Santana
 
PPTX
TDC 2012 TDD e 20 coisas que você precisa saber
porCamilo Lopes
 
PDF
BDD - JBehave + SeleniumHQ + PhantomJS + Fixture Factory
porAndre Vinicius Buzzo
 
PDF
Test driven development teste e design no mundo real by mauricio aniche (z-li...
porGessdaSilvaMachado
 
Automatizando testes em 4 passos
porHélio Medeiros
 
Test Driven Development - Em busca de feedback util e concreto
porHélio Medeiros
 
Apresentacao tdc 2012
porJorge Oleques
 
Como TDD pode influenciar na construção do seu Produto?
porRaphael Paiva
 
Introdução ao TDD
porThiago Faria de Andrade
 
TDD com Python
porOsvaldo Santana Neto
 
Testes e mocks: Em Visual Studio com .NET
porAlessandro Binhara
 
Desenvolvimento orientado a testes
porCarlos Santana
 
Coding Dojo - Funcionamento
porthiagodp
 
O programador pragmático
poredgarddavidson.com
 
Seja Um Programador Pragmatico
porLeonardo Fernandes
 
O Programador Pragmático
porTadeu Marinho
 
TDD para Java EE
porDairton Bassi
 
Programação Pragmática
porelliando dias
 
Multidisciplinaridade - Desconstruindo especialistas e construindo times
porHélio Medeiros
 
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
porDeveloper Academy
 
Boas práticas no desenvolvimento de software
porCarlos Santana
 
TDC 2012 TDD e 20 coisas que você precisa saber
porCamilo Lopes
 
BDD - JBehave + SeleniumHQ + PhantomJS + Fixture Factory
porAndre Vinicius Buzzo
 
Test driven development teste e design no mundo real by mauricio aniche (z-li...
porGessdaSilvaMachado
 

Semelhante a TDD para "meros mortais"

PPTX
TDD Desenvolvimento orientado ao teste
porRafaela Prado
 
PPTX
TDD (Resumo)
porDenis Ferrari
 
PDF
Introdução ao TDD nas soluções Global AppCasting
porPedro Pereira Martins
 
PPTX
Introdução ao Test Driven Development (TDD)
porLucas Nery
 
PDF
Treinamento TDD - Atech
porcesarcneto
 
PDF
Por quê você deve utilizar TDD?
porWellington Moreira
 
PPTX
Paletra sobre TDD, ocorrida no #DevDojo
porflavio1110
 
PDF
Test-Driven Development serve pra mim?
porMaurício Aniche
 
PPTX
Desenvolvimento dirigido por comportamento e por teste
porUniversidade Tiradentes
 
PPTX
TDD (Test Driven Development)
porFelipe Pimentel
 
PPTX
Introdução a tdd
porFabrício Vargas Matos
 
PDF
TDD depois do mainstream. E agora?
porMaurício Aniche
 
KEY
Programação Orientada a Testes
porGregorio Melo
 
PDF
UnP Eng. Software - Aula 27
porHélio Medeiros
 
PPT
Test driven development
porCarlos Eduardo Miranda
 
PDF
Introdução ao TDD
porBreno Martinusso
 
PDF
All You Need Is TDD (Português)
porHuge
 
PPTX
Desenvolvimento orientado a testes - TDD
porwashingtonlslima
 
PPTX
TDD na Prática
porRafael Fuchs, PMP, MBA
 
PDF
Introdução ao TDD
porEduardo Mendes
 
TDD Desenvolvimento orientado ao teste
porRafaela Prado
 
TDD (Resumo)
porDenis Ferrari
 
Introdução ao TDD nas soluções Global AppCasting
porPedro Pereira Martins
 
Introdução ao Test Driven Development (TDD)
porLucas Nery
 
Treinamento TDD - Atech
porcesarcneto
 
Por quê você deve utilizar TDD?
porWellington Moreira
 
Paletra sobre TDD, ocorrida no #DevDojo
porflavio1110
 
Test-Driven Development serve pra mim?
porMaurício Aniche
 
Desenvolvimento dirigido por comportamento e por teste
porUniversidade Tiradentes
 
TDD (Test Driven Development)
porFelipe Pimentel
 
Introdução a tdd
porFabrício Vargas Matos
 
TDD depois do mainstream. E agora?
porMaurício Aniche
 
Programação Orientada a Testes
porGregorio Melo
 
UnP Eng. Software - Aula 27
porHélio Medeiros
 
Test driven development
porCarlos Eduardo Miranda
 
Introdução ao TDD
porBreno Martinusso
 
All You Need Is TDD (Português)
porHuge
 
Desenvolvimento orientado a testes - TDD
porwashingtonlslima
 
TDD na Prática
porRafael Fuchs, PMP, MBA
 
Introdução ao TDD
porEduardo Mendes
 

TDD para "meros mortais"

  • 1.
    TDD para “merosmortais” Porque a vida real é mais que Fibonacci!
  • 2.
    Quem sou eu? ThiagoBaptista Desenvolvedor há uns 3 anos (principalmente Java) Entusiasta do Software Livre e do Movimento Ágil Tarado por Computação e estudar novas tecnologias...
  • 3.
    Quem sou eu? ...UM“MERO MORTAL”!!! Não sei nem 40% do que ACHO que sei Não sei nem 30% do que eu DEVERIA saber Vivo no “mundo real”
  • 4.
    Como assim, “mundoreal”? Agilidade é (ainda) desconhecida Empresas são “fábricas de software” Relação cliente-empresa é conflituosa Prazos estouram, retrabalho, código “macarrônico” etc. Maioria dos projetos é manutenção de código legado
  • 5.
    Desenvolvedores do “mundoreal” Não têm larga experiência Se concentram em uma tecnologia Foram educados em uma metodologia de trabalho Na faculdade vivem um mundo totalmente distante do mercado de trabalho (Swing?? Dicionário de dados??? UML é “novidade”?!?)
  • 6.
    O trabalho dodesenvolvedor na “vida real” Empresas que há muitos anos trabalham da mesma forma Gerentes e chefes que desconhecem o ofício Ou, quando conhecem, estão MUITO desatualizados Num constante clima de correria e prazos estourados Sem tempo ou recursos para se atualizar Sem incentivo para se atualizar
  • 7.
    Dialética do desenvolvimentode software Tese: de um lado, essa “vida real” Antítese: do outro, novas e muito melhores técnicas, metodologias e tecnologias Síntese: ???
  • 8.
    Desenvolvedor “ágil” hoje:meu caso Li e estudei bastante sobre isso Vi na prática acontecer e dar certo Defendo e procuro aplicar isso Porém...
  • 9.
    Desenvolvedor “ágil” hoje:meu caso ...SOU UM MERO MORTAL!!! Conheço bem a teoria, mas tenho pouca experiência prática Portanto, sei muito menos do que eu ACHO que sei Tive pouquíssimas oportunidades de colocar em prática
  • 10.
    TDD para “merosmortais” Estudo de caso: um “mero mortal” aplicando a teoria do TDD na prática!
  • 11.
  • 12.
    Desenvolvimento (ou design)guiado por testes Escreve-se um teste primeiro, e só depois o código “real” Código “real” é sempre fruto de se fazer um teste escrito previamente passar Test-Driven Development/Design
  • 13.
    TDD em essência SegundoKent Beck, “autor” da técinca: Escreva um teste automatizado que falhe antes de escrever qualquer outro código Escreva um código para fazer esse teste passar Remova a duplicação
  • 14.
    TDD em essência SegundoKent Beck, “autor” da técinca: Escreva um teste automatizado que falhe antes de escrever qualquer outro código [VERMELHO] Escreva um código para fazer esse teste passar [VERDE] Remova a duplicação [REFATORAR] ...repetir o processo...
  • 15.
    Conceitos importantes Só podehaver código “real” se houver antes um teste que falhe Deve-se avançar com “passinhos de bebê” (baby steps) Só se adiciona um novo teste que falhe após todos os outros testes estarem “verdes”
  • 16.
    Baby steps Faz-se omínimo necessário para o teste ficar “verde” Após o “verde”, refatora-se para eliminar a redundância Cria-se um novo teste para “quebrar” novamente Faz-se o mínimo necessário para ambos os testes passarem Refatora-se de novo Repete-se o processo até ter código “real” funcionando “de verdade”
  • 17.
    Clássico exemplo: multiplicarpor 2 Funcionalidade: um método que receba um inteiro como argumento e retorne o produto deste por 2 Exemplos: multiplicar(5) == 10 multiplicar(13) == 26 multiplicar(0) == 0
  • 18.
    Clássico exemplo: multiplicarpor 2 Primeiro passo: um teste que falha
  • 19.
    Clássico exemplo: multiplicarpor 2 Segundo passo: implementar o mínimo absoluto pro teste passar
  • 20.
    Clássico exemplo: multiplicarpor 2 Terceiro passo: novo teste que falha e “quebra” o código
  • 21.
    Clássico exemplo: multiplicarpor 2 Quarto passo: implementar, novamente, o mínimo para os dois testes passarem
  • 22.
    Clássico exemplo: multiplicarpor 2 Quinto passo: refatorar para eliminar a redundância
  • 23.
    Clássico exemplo: multiplicarpor 2 Enésimo passo: repetir até ter a segurança para implementar o código “de verdade”, de produção
  • 24.
    Conclusões e benefícios TDDé como a rede de proteção dos malabaristas no circo De quebra, ainda te dá uma cobertura de testes Garante que o código faça o mínimo necessário Manter esse código: mel na chupeta! É só continuar com o processo do TDD de onde parou Garante a aprendizagem do código
  • 25.
  • 26.
  • 27.
    Na manufatura... Você sabede antemão o resultado que quer (você tem o “molde”) O processo de construção é determinístico Para cada resultado esperado, um processo determinado f(x) = y O processo de construção é conhecido previamente O processo de construção pode ser replicado
  • 28.
  • 29.
    Desenvolver software é traduzir CONHECIMENTOSDE NEGÓCIO para ALGORÍTMOS COMPUTACIONAIS
  • 30.
  • 31.
  • 32.
    Você não sabe: Sobreo negócio, tão bem quanto o cliente Sobre a real necessidade de um requisito na “hora H” Se o cliente sabe o que quer ou se você o entendeu direito Se no futuro os requisitos mudarão Se você está traduzindo o conhecimento direito Se você sabe desenvolver software
  • 33.
    Lição número 1 TDDé sobre o aprendizado do código
  • 34.
    Aprendizado?? Mas eu seimultiplicar um número por 2...
  • 35.
    TDD na “vidareal” “Multiplicar por 2”, Fibonacci, Fatorial etc. são exemplos conceituais A “vida real” é muito mais complexa CRUDs que lidam com persistência Aplicações web que lidam com a camada HTTP Threads, computação assíncrona etc.
  • 36.
    Estudo de caso:cliente para o WebPagetest
  • 37.
    Estudo de caso:cliente para o WebPagetest http://www.webpagetest.org Aplicação web para testar desempenho de sites Fornece uma API REST, mediante inscrição (gratuita) https://sites.google.com/a/webpagetest.org/docs/advanced- features/webpagetest-restful-apis Gera relatórios na web, via XML ou JSON
  • 38.
    O desafio: Cliente delinha de comando (shell) para o WebPagetest Para rodar de tempos em tempos (cron) Deve iniciar um teste para um site específico Deve aguardar o teste terminar e saber quando isso acontecer Deve obter o relatório do teste e exibir os dados conforme requerido
  • 39.
    Os obstáculos: API comnúmero reduzido de chamadas permitidas Só 200 testes num período de 24hs Ter que usar a camada HTTP Trabalhar com XMLs (API JSON muito limitada na época) Trabalhar com a linha de comando Para chamar a aplicação e iniciar o teste Para exibir os resultados do teste Salvar resultados no sistema de arquivos (em logs)
  • 40.
    As ferramentas: Plataforma Java Groovy APIHTTP nativa API de XML nativa API de testes nativa API nativa para trabalhar com a linha de comando (Groovy CLI) TDD
  • 41.
  • 42.
  • 43.
    Tá, mas... poronde começar??
  • 44.
    Aplicando o TDD Minhaprincipal dúvida: por onde começar um projeto da “vida real” Qual classe? Qual caso de uso ou história do usuário? Qual método? Qual funcionalidade? Se uso um framework, devo começar o testando também? Maior “defeito” do ensino do TDD - onde se começa
  • 45.
    E por falarem “começos”...
  • 46.
    Testes “tradicionais” eTDD “Teste”, tradicionalmente, faz parte da linguagem do controle de qualidade (“Quality Assurance” - QA) Testa-se para saber se algo que já existe se conforma a padrões esperados de comportamento e qualidade Todo um mundo de metodologias, técnicas, certificações etc. Todo um linguajar próprio: Teste de unidade, de integração, de regressão, de aceitação Teste “caixa-preta”, “caixa-branca”, “caixa-cinza” etc.
  • 47.
    Testes “tradicionais” eTDD O profissional de QA planeja a execução dos testes conforme os requisitos, testa e, então, gera seus artefatos
  • 48.
    TDD não ésobre QA!
  • 49.
    QA é muitoimportante, mas não é disso que estamos falando...
  • 50.
    TDD e “tiposde teste” O linguajar sobre testes, em TDD, quer dizer coisas diferentes do que quer dizer em QA Teste de unidade geralmente se refere à “testar classes” Teste de integração/aceitação geralmente se refere a testar funcionalidades
  • 51.
    Então, por queo “T”? Na verdade, o “teste” representa uma expectativa, um propósito que o código deve atender O propósito desse método é multiplicar a entarda por 2 O propósito dessa classe é se conectar a um SGBD O propósito desse módulo é ser um adaptador de uma API externa para nossa Etc.
  • 52.
    Sendo assim, érealmente um “T”? Um propósito é o reflexo de uma necessidade que o código deve atender Fazemos escolhas de projeto (design) do código para atender essa necessidade É um “teste” na medida em que garante que o projeto do nosso código atenda a essa necessidade
  • 53.
    Portanto, não ésobre “teste”...
  • 54.
  • 55.
    Lição número 2 TDDé sobre o projeto, sobre o design do código
  • 56.
    Estamos destacando apalavra errada...
  • 57.
  • 58.
  • 59.
    Sobre por ondecomeçar Segundo a teoria: de “cima para baixo” Do ponto de vista do usuário Com um “teste de aceitação” que representa uma funcionalidade Teste que só passaria com a integração de todo o sistema Ou seja: do HTML à JPA, passando pelo modelo
  • 60.
    Mas e senão der pra ser assim?
  • 61.
    Começe de ondeder pra começar!!!
  • 62.
    Lição número 3 Quandoem dúvida, começe o TDD de onde você se sentir mais confortável
  • 63.
    Começando pelo maisconfortável Pelo elemento mais básico do código que resolva o problema em questão A classe mais óbvia O método mais fácil de se fazer O módulo com menos dependências
  • 64.
    Exemplo prático: clienteWebPagetest O começo mais óbvio de qualquer código... é ele existir! Deve haver um objeto que represente o sistema que queremos construir - o WPTClient
  • 65.
    Exemplo prático: clienteWebPagetest Próximo passo: deve fazer o óbvio! Nosso objeto deve ser capaz de executar sua funcionalidade mais básica.
  • 66.
  • 67.
    O segundo testeclaramente “cobre” o propósito do primeiro - garantir que exista um objeto WPTClient. Portanto...
  • 68.
  • 69.
    Opa! O códigodo teste também evoluiu!
  • 70.
    Lição número 4 Ocódigo do “teste” também “é código” e, portanto, também evolui
  • 71.
    Teste também “écódigo”! O código do teste também progride conforme o aprendizado do código progride “É código”, portanto: atenção às boas práticas! Código limpo Eliminar “bad smells” OO “de verdade”
  • 72.
    WPTClient e evoluçãodo código Com o tempo, a classe WPTClient passou a ter muitas responsabilidades: Existir Iniciar o teste Se conectar à camada HTTP Acessar a URI correta e mandar a requisição correta à API do WebPagetest...
  • 73.
    WPTClient: e osmétodos “internos” Dúvida muito comum: como fazer TDD de métodos privados? Ou de algoritmos internos a um método void? Resposta geral: testa-se o estado que o método “interno” altera Se o resultado do cálculo matemático está correto Se o HTML está corretamente formatado Se a lista tem o número de membros esperado
  • 74.
    WPTClient inicia testenuma URL WTPClient deve iniciar um teste numa URL válida WPTClient não deve iniciar um teste numa URL inválida
  • 75.
    WPTClient inicia testenuma URL Supondo que estejamos prontos pra criar a implementação “de verdade”, isso implica em: Acessar a API HTTP do Groovy “de verdade” Preparar a chamada à API “de verdade”
  • 76.
    WPTClient inicia testenuma URL Opa! Se conectar à web de verdade? A API tem um número limitado de chamadas permitidas Se trata da integração com uma parte “externa” a essa “unidade” E se no dia a Internet cair? E se der errado, como vou saber que é problema do meu código, e não da infraestrutura de redes?
  • 77.
    Evoluindo o código:novas classes Solução: refatorar o método iniciarTeste() para usar novos objetos Transferir essas responsabilidades para os devidos objetos Com isso: Testa-se os objetos, e não um método “fechado” Elimina-se o acoplamento da classe WPTClient
  • 78.
  • 79.
  • 80.
  • 81.
    Lição número 5 TDDé sobre projeto de código evolutivo, que cresce e se desenvolve como um organismo vivo
  • 82.
    Código evolutivo TDD permitecultivar o código, como uma planta que cresce Seu “DNA” - os requisitos, o propósito a qual o código serve Novas classes surgem como novas células Desenvolvimento não linear do código Novas classes surgem conforme a necessidade Novos testes surgem conforme a necessidade
  • 83.
    O código “fala” contigo,dizendo pra onde você deve ir!
  • 84.
    Evolução do código:onde ocorre? Só pode haver evolução se há testes (propósitos) sendo atendidos É fruto de atender melhor a esses propósitos Assim, ocorre com a refatoração Portanto, a etapa da refatoração não pode ser negligenciada!
  • 85.
    Lição número 6 Éimpossível o código evoluir sem haver a refatoração
  • 86.
    Refatoração e evoluçãodo código É onde os padrões de projeto OO são postos em prática É onde se identifica a necesidade de se evoluir o código É onde se descobre os “ganchos” para isso acontecer
  • 87.
    Exemplo: motor devideojogo Classe WalkerGameObject, desenvolvida com TDD Testes passando (VERDE) If...else...if...else...if... OO mandou lembranças...
  • 88.
  • 89.
    E por falarem qualidade do código...
  • 90.
    Voltando aos métodosprivados... Métodos privados ou com “algoritmos internos” não são facilmente testáveis
  • 91.
    Testando essa classe... Comoeu sei se o Produto recebido está ou não nulo? Como eu sei que getNotNullProperties() só retornou propriedades não nulas? Como eu sei se consegui criar direito um DataSourceConnection? Como eu sei se o método filter() realmente filtrou? Como eu sei se o método replaceProperties() funcionou?
  • 92.
    Epa! E nãoé só isso!
  • 93.
    A classe ProductParser... Temmais de uma responsabilidade Assegurar que o Porduto não seja nulo Criar e gerenciar uma classe que faz conexão com o sistema de arquivos Gerenciar e alterar as propriedades do Produto Está altissimamente acoplada às suas dependências
  • 94.
  • 95.
    É difícil detestar... E ...é mal escrita (alto acoplamento, várias responsabilidades...)
  • 96.
  • 97.
  • 98.
    É consequência! O principalproblema da “testabilidade” do código é que ele é mal projetado Segundo Michael Feathers, alto acoplamento é a maior dor de cabeça de se lidar com código legado Portanto: código projetado pra “ser testável” é código bem projetado!
  • 99.
    Lição número 7 TDDgarante o melhor projeto de código; se um código não é “testável”, ele está errado
  • 100.
    TDD e qualidadede código Não lute contra a dificuldade de se criar um teste! Provavelmente, significa que há uma forma melhor de se projetar o código Exemplo: testar a existência do loop principal de um videojogo
  • 101.
    WPTClient e qualidadede código Exemplo: trabalhar com o XML de resposta do teste
  • 102.
    Possível solução: APIde XML do Groovy
  • 103.
    Porém... E se essaAPI não funcionar para o que eu quero? E se a API mudar no futuro? E se o XML de resposta mudar no futuro? O código ficara acoplado a essa API!
  • 104.
    O que dizo TDD mesmo...? Código “real” é sempre fruto de se fazer um teste escrito previamente passar
  • 105.
    Portanto... Criemos o testepara haver a classe Resposta!
  • 106.
    Ao seguirmos oTDD “à risca”... Ganhamos a classe Resposta Desacoplamos nossa implementação das duas APIs (de XML e do WebPagetest) Garantimos a cobertura de testes Tornamos a futura manutenção dessa classe um “passeio no parque”
  • 107.
    Devemos seguir TDD“à risca” porque...
  • 108.
    Lição número 9 TDDé um processo contínuo que, pra funcionar, não deve ser interrompido
  • 109.
    Se você parade usar TDD numa parte do código, o sistema todo pode ruir!
  • 110.
    Afinal, TDD ésobre DESIGN, não sobre testes!
  • 111.
    WPTClient e ocódigo “macarrônico” Por pura negligência, fiz a parte da linha de comando sem TDD... É a parte mais horrenda do código Mantê-la será um pesadelo para a heroina ou o herói que se habilitar...
  • 112.
    Resultado: Erro na horade imprimir no shell o resultado dos testes Erro ao salvar o arquivo dos testes no sistema de arquivos Gastei horas pra resolver a questão dos parâmetros da linha de comando Percebi que li a API errada e tive que refazer umas 60 linhas de código!
  • 113.
    TDD como processocontínuo Ou o código é fruto da certeza de que ele atende um propósito, ou ele é código incerto Segundo Michael Feathers: código legado é todo código sem teste! Mesmo o código que você acabou de escrever
  • 114.
    Lição número 10 Nunca,jamais subestime a necessidade dos baby steps
  • 115.
    WPTClient: herança daclasse Resposta Na API do WebPagetest, há um único XML de resposta, porém ela pode ser: De falha ao iniciar o teste De teste iniciado De teste em andamento De teste concluido O relatório em si do teste
  • 116.
    WPTClient: a classeResposta Desenvolvida por TDD Também com o “if-else hell”...
  • 117.
    Jogando o TDDpro espaço... Sem seguir o processo de baby steps, criei toda uma hierarquia de classes “Resposta” Interface “Resposta” Classe “TesteIniciado” Classe “TestePendente” Etc.
  • 118.
  • 119.
  • 120.
    O sistema inteiro“quebrou”!!
  • 121.
  • 122.
    Resultado? Tive que desfazertodas as alterações Tive que garantir que todos os testes continuassem passando Aprendi a lição
  • 123.
    Mas... e aqualidade do código? E as “boas práticas”?
  • 124.
    Lição número 11 TDDgarante a qualidade funcional do código, e não necessariamente a “estética”
  • 125.
    TDD sem “purismos” Código“dentro dos padrões” é consequência no TDD, não o objetivo primordial Padrões de projeto, por si só, não garantem um código funcional Se no futuro for necessário, o TDD garante a “beleza” do código - refatoração
  • 126.
    TDD e integração Comofazer TDD em sistemas com integrações/dependências externas? CRUDs com JPA Aplicações web Teste unitário? De integração? De aceitação?
  • 127.
  • 128.
  • 129.
    A “integração” éum propósito em si do código!
  • 130.
    Lição número 12 Integraçãode sistemas/módulos em TDD é função do projeto do código, e não do “tipo” de teste
  • 131.
    TDD e integração Aresponsabilidade de uma classe é um propósito: A classe FormatadorDeString formata strings... A classe ProdutoComparator compara produtos... A classe URLValidator valida URLs... E a integração com um sistema/módulo externo também é um propósito!
  • 132.
    WPTClient e integração Exemploprático de integração: WPTClient e requisições HTTP Se conectar “de verdade” à web é um requisito... ...portanto um propósito... ...portanto deve ser projetada guiando-se em testes.
  • 133.
    WPTClient e integração Duascoisas distintas a se testar: Se a classe WPTClient é capaz de se conectar à camada HTTP - a “unidade” Se a integração do nosso sistema com o HTTP funciona “de verdade” - a “integração” De onde surge essa distinção? Dos testes.
  • 134.
    WPTClient e integração Testandoa “unidade”, obtivemos isso:
  • 135.
    WPTClient e integração Paratestar a “unidade”, fizemos isso:
  • 136.
    WPTClient e integração E,para testar a “integração”, obtivemos isso:
  • 137.
    E depois dessaexperiência?
  • 138.
    Continuo um “meromortal”... Como fazer TDD em código legado? TDD em equipe: como evitar “quebrar” o processo? TDD “avançado”: threads, computação assíncrona etc. TDD vs BDD
  • 139.
    Bibliografia BECK, Kent. “TDDby Example” FREEMAN, Steve & PRICE, Nat. “Growing OO Software Guided by Tests” FEATHERS, Michael. “Working Effectively with Legacy Code” KOSKELA, Lasse. “Test Driven: TDD and Acceptance TDD for Java Developers”
  • 140.