Testes e RefatoraçãoTestes e Refatoração

JevôPaulo César M. Jeveauxwww.jeveaux.comj

refatore

Escreva códigoEscreva umTeste

Escreva códigoque passeno teste

J ôJevô

• Analista Senior de WebMedia na globo.com

• Desenvolvedor Java há 7++ anos

• Administrador do PortalJava e ESJUG

• Palestrante‐Entusiasta‐Evangelista Java• Palestrante‐Entusiasta‐Evangelista Java

h l l• Entusiasta Python, Rails e Agile

A dAgenda

• Introdução

• Bug

• Você confia no que faz? Afinal é um teste?• Você confia no que faz? Afinal é um teste?

• Cobertura de testes

• Tipos de testes

• Desenvolvendo orientado a testes

F t té i d t t• Ferramentas e técnicas de testes

• RefatoraçãoRefatoração

IntroduçãoIntrodução

Desen ol imento de soft areDesenvolvimento de software

IntroduçãoIntrodução

Desen ol imento de soft areDesenvolvimento de software

Falhas de SoftwareFalhas de Software

F lh d S ftFalhas de Software

• Mais de 1/3 das falhaspoderiam ser evitadaspoderiam ser evitadascom testes; [1]

• Cerca de 50% das falhasCerca de 50% das falhassó são descobertas emprodução;produção; [1]

IntroduçãoIntrodução

Desen ol imento de soft areDesenvolvimento de software

Falhas de SoftwareFalhas de Software

Falhas custam caro

F lh t $$$Falhas custam $$$

• Segundo uma pesquisa do Departamento de C é i d EUA bli d 2002 f lhComércio dos EUA, publicada em 2002, falhas de software são tão comuns e tão danosas que se estima que causem um prejuízo anual de mais de 60 bilhões de dólares para ade mais de 60 bilhões de dólares para a economia americana. [1], [2]

IntroduçãoIntrodução

Desen ol imento de soft areDesenvolvimento de software

Falhas de SoftwareFalhas de Software

Falhas custam caro

Testes não evitam falhas

IntroduçãoIntrodução

Desen ol imento de soft areDesenvolvimento de softwareFalhas de SoftwareFalhas custam caro

Testes não evitam falhasTestes identificam as falhas antes delasTestes identificam as falhas antes delas

acontecerem

BugBug

O que é?

BBugs

São aquelas baratinhas queSão aquelas baratinhas que 

fi ál l d ificavam nas válvulas do Eniac

BBugs

Podem ser os insetos no vidro doPodem ser os insetos no vidro do 

carro

BBugs

E também podem ser milhões deE também podem ser milhões de 

bloutros problemas que somente 

os usuários irão encontrar

BBugs

E também podem ser milhões deE também podem ser milhões de 

bloutros problemas que somente

os usuários irão encontrar

BBugs

Por mais perfeita que seja suaPor mais perfeita que seja sua 

h i b ãengenharia, os bugs estarão 

presentes e afetarão diretamente 

o usuárioo usuário

BBugs

Metodologias ágeis, como o XP, defendem g g , ,

que, ao encontrarmos um problema,que, ao encontrarmos um problema, 

antes de desenvolver uma soluçãoantes de desenvolver uma solução 

devemos criar um teste que detecte taldevemos criar um teste que detecte tal 

blproblema.

Você confia no que faz?Você confia no que faz?

G t ê fGaranta o que você faz

• Cliente:– Isso aqui não está funcionando!

• Programador:–Mas como!? Na minha máquina estava funcionando até ontemfuncionando até ontem.

G t ê fGaranta o que você faz

Depois eu escrevo o pplano de testes…

G t ê fGaranta o que você faz

Depois eu escrevo o pplano de testes…

Vamos deixar os testes pra próxima fase…

G t ê fGaranta o que você faz

Depois eu escrevo o pplano de testes…

Vamos deixar os testes pra próxima fase…

Na minha máquina estáNa minha máquina estáfuncionando…

G t ê fGaranta o que você fazD iDepois eu escrevo o plano de testesplano de testes…

Vamos deixar os testes pra próxima fase…

Precisamos entregar o produto semana que vem!!!

Na minha máquina estáfuncionando…

G t t b lh j fi i lGaranta o seu trabalho seja profissional

Errado! (como se safar) Realidade!

• Num mundo capitalizado 

não há tempo para testes

• O cliente não quer saber se 

X virou Y Ele quer que onão há tempo para testes

• O cliente não quer saber 

X virou Y. Ele quer que o 

problema não aconteça e se q

como é feito, ele quer que  acontecer que seja corrigido 

funcione rapidamente

• Não se consegue qualidade• Não se consegue qualidade 

e confiabilidade sem testes[4]

O que são testes?O que são testes?

O ã t t ?O que são testes?

Um teste é uma verificação feita sobre um 

código ou fragmento de código para garantir 

que uma determinada entrada produza, 

sempre, uma saída esperada

O ã t t ?O que são testes?

• São pontuaisSão pontuais

• São previsíveis

• São finitosSão finitos

• São (ou deveriam ser) simples

O que são testes?O que são testes?

White BoWhite Box

Whit BWhite Box

• Testes de unidade de código;g ;

• Testam parte da solução;• Testam parte da solução;

• São escritos e mantidos pelo 

programador e devem estar sempre 

atualizados;

O que são testes?O que são testes?

White BoWhite Box

Black BoxBlack Box

Bl k BBlack Box

• Testes funcionais e de aceitação;Testes funcionais e de aceitação;

d i ã• Testes de integração;

• Testam a solução completa;

C b t d t tCobertura dos testes

Trecho alterado Resultado esperado com alteração: OKcom alteração: OK

Reflexo da alteraçãoReflexo da alteraçãoErro #1

Reflexo da alteraçãoErro #2

Reflexo da alteraçãoBUG

Reflexo da alteraçãoI dInesperado

C b t d t tCobertura dos testes

Sem cobertura Com cobertura

• Novo release = códigos sem testes;

• Não há segurança deNão há segurança de que as alterações não irão impactar em outrosirão impactar em outros pontos da aplicação;

• Problemas muitos• Problemas, muitos problemas;

C b t d t tCobertura dos testes

• Dificilmente consegue‐se 100% de cobertura 

de testes, contete‐se com 99%

• Quanto maior a cobertura dos testes na 

aplicação maior a confiabilidade nas 

alterações e novos recursos

C b t d t tCobertura dos testes

• Aplicações cobertas por bons testes i ipropiciam:

Facilidade de manutenção;– Facilidade de manutenção;

– Facilidade para inclusão de novos membros no– Facilidade para inclusão de novos membros no 

time de desenvolvimento;;

– Redução de problemas e custos nas manutenções;ç p ç

– Telefone silencioso nas madrugadas!

T t ã á iTestes são necessários

• Você precisa verificar o código, sempre

• Você precisa garantir que os requisitos estão p g q q

implementados (e corretos)p ( )

• Você precisa ter segurança para realizarVocê precisa ter segurança para realizar 

alteraçõesç

T t ã á iTestes são necessários

• Você precisa testar rápido para entregar rápido

• Você precisa ser criativo para explorar o máximo 

possível com seus testes, não use testes mentirosos

• Você aumenta e garante a qualidade da sua solução 

com testes

Tipos de TestesTipos de Testes

Unitário

T t U itá iTestes Unitários

• Testam uma parte isolada da solução, um 

componente ou trecho de código

• Todo o resto é simulado através de Mock 

Objets;

• É fundamental para TDDp

T t U itá iTestes Unitários

[wikipedia]

É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas

O universo alvo desse tipo de teste são os métodos dos objetosO universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

[/wikipedia]

T t U itá iTestes Unitários

• Ferramentas:

– JUnit/NUnit e TestNG: para testes unitários

– JMock: para criação de objetos e cenários falsos

Tipos de TestesTipos de Testes

Unitário

Aceitação

T t d it ãTestes de aceitação

• Testam uma história, funcionalidade ou caso 

de uso

• Envolvem vários componentes do sistema ou p

até o sistema como um todo

• Ex. ferramentas: JUnit, Selenium, Fit/FitNesse, , /

Tipos de TestesTipos de Testes

Unitário

Aceitação

IntegraçãoIntegração

T t d i t ãTestes de integração

• Testam a integração entre componentes

• Envolvem dois ou mais componentesp

• Ex ferramentas: JUnit DBUnit HSQLDBEx. ferramentas: JUnit, DBUnit, HSQLDB

• Normalmente não é muito utilizado em TDD• Normalmente não é muito utilizado em TDD

Test‐Driven DevelopmentTest Driven Development

TDDTDD

refatore

E Escreva códigoEscreva umTeste

Escreva códigoque passeno teste

R F d t iRegras Fundamentais

• Escreva o teste da implementação ANTES de 

escrevê‐la

• Escreva somente código suficiente para o g p

teste passar e nada além disso

• Escreva testes pequenosp q

• Escreva testes muito rápidosEscreva testes muito rápidos[10]

FerramentasFerramentas

JUnit

JU itJUnit

• É um framework altamente eficaz e l t tili d i ã ã dlargamente utilizado na criação e execução de testes unitários de códigosg

http://junit.org

U t t JU itUm teste com JUnit

public class HelloWorldTest {@Test@ estpublic void testMultiplicacao() {

//Testando se 2*2 = 4assertEquals (“Mult”, 4, 2*2);assertEquals ( Mult , 4, 2 2);

}}

FerramentasFerramentas

JUnit

TestNG

T tNGTestNG

• Uma alternativa ao JUnit para testes unitários

• Foi o primeiro a utilizar anotações para p ç p

definição dos TestCasesç

T tNGTestNG

U t t T tNGUm teste com TestNG

import org.testng.annotations.*;

public class SimpleTest {@BeforeClass@BeforeClasspublic void setUp() {}}@Test(groups = { "calculadora" })

bli id T t() {public void somaTest() {System.out.println("soma");

}}}

FerramentasFerramentas

JUnitTestNGTestNGJMock

JM kJMock

• Utilizado para criar ou simular falsos 

objetos/cenários

• Alternativas:

– EasyMock

–MockObjetc

S l iSelenium

• Ferramenta para realização de testes 

integrados e de aceitação

• Usado no browser, grava todos os passos , g p

executados na aplicação diretamente no 

browser e os executa de forma automatizada 

no browser

S l iSelenium

ClClover

• Ferramenta para análise de cobertura dos 

testes existem na aplicação

• Integrado a várias IDEs ‐ Eclipse ;‐)g p ; )

• Existem diversas opções semelhantes:Existem diversas opções semelhantes: 

JCoverage, Cobertura, etcg , ,

ClClover

RefatoraçãoRefatoração

C d llCodesmell

• Codesmell ou code smell é um dos conceitos 

criados pelo XP

• Um code smell é uma indicação superficial de ç p

que algo pode estar errado. Aquela mesma 

sensação quando você abre sua geladeira e 

sente um cheiro estranho

O que é refatorar?O que é refatorar?

R f t ãRefatoração

• Sempre existiu, mas não tinha um nome

• Estava implícitop

• A novidade foi criar um vocabulário comum eA novidade foi criar um vocabulário comum e 

catalogá‐loscatalogá los

• Assim podemos utilizar mais sistematicamenteAssim podemos utilizar mais sistematicamente 

e ensinar uns aos outrose ensinar uns aos outros

Q d f t ?Quando refatorar?

• Sempre há duas possibilidades:

–Melhorar o código existente.

– Jogar fora e começar do 0.

• É sua responsabilidade avaliar a situação e 

decidir quando é a hora de optar por um ou 

por outro.

R f t ãRefatoração

• Os principais objetivos são:

– Tornar o código mais claro, limpo, simples e 

elegante;

– Permitir que componentes mais simples ou 

expressões mais eficientes sejam usadas.

R f t ã B fí iRefatoração: Benefícios

• Redução de código duplicado

• Aumentar a simplicidadep

• Facilitar a leituraFacilitar a leitura

• Melhorar a performance e eficência• Melhorar a performance e eficência

• Manutenibilidade• Manutenibilidade

R f t X RRefatorar X Reescrever

Refatorar Reescrever

• Não altera afuncionalidade ou

• Altera afuncionalidade dofuncionalidade ou

conteúdo doi t / l ã

funcionalidade dosistema/solução

sistema/solução

Garanta‐se nos testesGaranta se nos testes

Altere o código sem medo

G t t tGaranta‐se nos testes

• Antes de começar a refatorar verifique se você 

tem um conjunto de testes para garantir a 

funcionalidade do código a ser refatorado

• Refatorações podem adicionar erros

• Os testes vão ajudá‐lo a detectar erros se eles j

forem criados

C l õConclusões

• Testes colaboram para o aumento da lid d d i tqualidade dos sistemas;

• Desenvolvedores ficam mais corajosos eDesenvolvedores ficam mais corajosos e confiantes ao programar;

• O software cresce de forma ordenada e com qualidade de design;qualidade de design;

• O software se adapta com mais facilidade a mudanças;

C l õConclusões

• Demora mais?– No início é necessário escrever muitos testes;;– Depois da inércia a suite de testes está pronta e escrevem‐se menos testes;

– Certeza de que a implementação está funcionando;– Maioria dos bugs encontrados em tempo de d l i tdesenvolvimento;

– Bugs de produção são encontrados e corrigidos com muito mais velocidade;mais velocidade;

• Então no fim das contas demora‐se muito menos tempo e com muito mais qualidade;tempo e com muito mais qualidade;

[10]

Dúvidas?Dúvidas?

R f ê iReferências• [1] ‐ NIST ‐ http://www.nist.gov/public_affairs/releases/n02‐10.htm• [2] ‐ ImproveIt ‐ http://www.improveit.com.br/xp/praticas/tdd• [3] ‐ Caelum ‐ http://blog.caelum.com.br/2006/09/08/voce‐acredita‐no‐seu‐codigo/[ ] p // g / / / / g /• [4] – Fragmental ‐ Shoes ‐ http://blog.fragmental.com.br/2007/10/31/programadores‐

profissionais‐escrevem‐testes‐ponto‐final/• [5] – Marcos Pereira – http://marcospereira.wordpress.com/2007/11/27/desenvolvedores‐

d i t todeiam‐testar • [6] – Wikipedia – http://en.wikipedia.org/wiki/Test‐driven_development• [7] ‐ TDD ‐ http://www.testdriven.com• [8] Brod http://www brod com br• [8] ‐ Brod ‐ http://www.brod.com.br • [9] – java.net ‐ http://wiki.java.net/bin/view/People/SmellsToRefactorings • [10] – Palestra Desenvolvimento Guiado por Testes (TDD) – Guilherme Chapiewski

• Algumas ilustações foram retiradas do site da ImproveIt.

refatore

E Escreva códigoEscreva umTeste

Escreva códigoque passeno teste

D íd C íti S tõDuvídas, Críticas e Sugestões

• Para contato:–www.jeveaux.com

t lj–www.portaljava.com–paulo@jeveaux.compaulo@jeveaux.com

– jeveaux@portaljava.com

Obrigado a todos!Obrigado a todos!27/09/2008