Testes e Refatoração

Testes&

Refatoração

Testes&

Refatoração

por Paulo César M. Jeveaux03/03/2008 – 05/03/2008

| Paulo César M. Jeveaux (Jevô)

• Consultor e Arquiteto de soluções Java na Inflor;

• Mantenedor responsável do PortalJava.com e ESJUG;

• Palestrante-Entusiasta-Evangelista Java;

| Testes

• Planejamento: User stories

• O que é um bug• Como simular e detectar

um bug• Praticando: Testes

automatizados• Testes unitários• Ferramentas: JUnit e

TestNG• Criando o seu teste• Praticando: Ao detectar

um bug, escreva um teste

• Corrigindo um bug• Testes de aceitação• Praticando: Integrando

sempre• Praticando: Todo código

precisa de testes unitários.

• Praticando: Todo código precisa passar nos testes unitários antes de serem lançados como produto.

• Retrospectiva

| Refatoração

• Praticando: Stand-up meeting• Codesmell• O que é refactoring• Praticando: Iteration planning• Garanta-se pelos testes• Alterando o código sem medo

| Introdução

Desenvolvimento de software

| Introdução


Falhas de Software

| Falhas de Software

• Mais de 1/3 dasfalhas poderiam ser evitadas com testes; [1]

• Cerca de 50% dasfalhas só sãodescobertas emprodução; [1]

| Introdução


Falhas de Software

Falhas custam caro

| Falhas custam $$$

• Segundo uma pesquisa do Departamento de Comé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 a economia americana. [1], [2]

| Introdução


Falhas de Software

Falhas custam caro

Testes não evitam falhas

| Introdução

Desenvolvimento de softwareFalhas de SoftwareFalhas custam caro

Testes não evitam falhasTestes identificam as falhas antes delas

acontecerem

| 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;


• São pontuais;

• São previsíveis;

• São finitos;

• São (ou deveriam ser) simples;


• Testes não verificam completamente a saída de um programa pois as entradas são finitas;

• Testes não são perfeitos para validação, mas são a melhor opção para isso;


White Box

| Caixa branca

• Testes de unidade de código;

• Testam parte da solução;

• São escritos e mantidos peloprogramador e devem estar sempreatualizados;

| Caixa branca

• Quando construímos um teste de unidade, o principal desafio é isolar a classe ou trecho de código que estásendo testado, para que nenhuma outra classe do sistema seja envolvida no teste e influencie no resultado esperado.


White Box

Black Box

| Caixa preta

• Testes funcionais e de aceitação;

• Testes de integração;

• Testam a solução completa;

| Cobertura de testes

Cobertura dos testes

Trecho alteradoResultado esperadocom alteração: OK

Reflexo da alteraçãoErro #1

Reflexo da alteraçãoErro #2

Reflexo da alteraçãoBUG

Reflexo da alteraçãoInesperado

| Cobertura dos testes

• Novo release = códigos sem testes;

• Não há segurança de que as alteraçõesnão irão impactarem outros pontos daaplicação;

• Problemas, muitos problemas;

Sem cobertura Com cobertura


• Dificilmente consegue-se 100% de cobertura de testes, contete-se com 99%;

• Quanto maior a cobertura dos testes naaplicação maior a confiabilidade nasalterações e novos recursos;


• Aplicações cobertas por bons testes propiciam:– Facilidade de manutenção;

– Facilidade para inclusão de novos membrosno time de desenvolvimento;

– Menos problemas e redução de custos emmanutenções;

– Telefone silencioso nas madrugadas!

| Testes são necessários

• Você precisa verificar o código, sempre;

• Você precisa garantir que os requisitosestão implementados (e corretos);

• Você precisa ter segurança para realizaralterações;

| Testes são necessários

• Você precisa testar rápido para entregarrápido;

• Você aumenta e garante a qualidade da suasolução com testes;

• Você precisa ser criativo para explorar o máximo possível com seus testes, não use testes mentirosos;

| Você confia no que faz?

| Garanta o que você faz

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

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

| Garanta o seu trabalho, sejaprofissional

Errado!

• Num mundo capitalizado não hátempo para testes;

• O cliente não quer saber como é feito, ele quer que funcione

Realidade!

• O cliente não quer saber se X virou Y. Ele quer que o problema não aconteça e se acontecer que seja corrigido rapidamente;

• Não se consegue qualidade e confiabilidade sem testes;[4]

| Test-Driven Development

| TDD

Escreva umTeste

Escreva códigoque passeno teste

refatore

| Dúvidas?

| XP

Extreme Programing

| Extreme Programming

• Metodologia de desenvolvimento de software;

• Originada nos Estados Unidos (anos 90);


• Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípiose práticas, que diferem substancialmente da forma tradicionalde se desenvolver software.


Valores

• Comunicação

• Coragem

• Feedback

• Respeito

• Simplicidade

Princípios

• Auto-semelhança

• Benefício Mútuo

• Diversidade | Economia

• Falha | Fluidez

• Humanismo | Melhoria

• Oportunidade

• Passos de Bebê

• Qualidade

• Redundância | Reflexão

• Responsabilidade Aceita


Papéis

• Analistas de Teste

• Arquitetos

• Designers de Interação

• Executivos

• Gerentes de Projeto

• Gerentes de Produto

• Programadores

• Recursos Humanos

• Redatores Técnicos

• Usuários

Práticas

• Ambiente Informativo

• Build de Dez Minutos

• Ciclo: semana/trimestre

• TDD

• Código Coletivo

• Continuidade da Equipe

• Escopo Negociável

• Reunião em Pé

• Refatoração

• Metáfora e muitos etc

| Histórias

User Stories

| Histórias

• As histórias permitem àqueles que conhecem a técnica da construção de uma solução (linguagem de programação, ferramentas, bases de dados) guiar quem necessita (usuários) desta solução no exercício de descrevê-la de forma simples e concisa. [8]

| Histórias

| Histórias

• As histórias apresentam três aspectos críticos, os quais devem ser obrigatoriamente lembrados no momento de sua criação. São eles: Cards, Conversation, Confirmation. Ou 3C.

| Histórias

• Cards: As histórias sãosempre escritas emcartões ou post-its.

• Conversation: A história escrita no cartão serve como um lembrete da conversa entre cliente e desenvolvedor;

• Confirmation: Depois das funcionalidades terem sido discutidas e escritas nos cartões, o cliente define (implícita ou explicitamente) uma maneira de validar esse pedido. Geralmente essa confirmação é feita com testes de aceitação.

| Histórias

• Para criar boas histórias, ainda devemos focar em seis atributos, também críticos, igualmente aos 3C, são eles:INVEST

| Histórias

• Independent:Histórias devem ser independentes uma das outras.

• Negotiable: Histórias não são contratos.

• Valuable: Histórias devem agregar valor para o cliente.

• Estimatable: Os desenvolvedores devem ser capazes de estimar o tamanhos das histórias .

• Small: Tamanho édocumento.

• Testable: Histórias devem ser possíveis de serem testadas.

| Dúvidas?

| Bug

O que é?

| Bugs

• Podem ser as baratinhas nas válvulas do Eniac;

• Os insetos no vidro do carro;

• E milhões de outros problemas quesomente os usuários irão encontrar;

| Bugs

• Por mais perfeita que seja sua engenharia, os bugs estarão presentes e afetarão diretamente o usuário;

• O bug mesmo, o real problema, só quem é capaz de detectar é o usuário final de um produto;

| Bugs

• Metodologias ágeis, como o Extreme Programming (XP), defendem que, ao encontrarmos um problema, antes de desenvolver uma solução devemos criar um teste que detecte tal problema.

| Bug

Como simular e detectar

| Bug

• Quando estamos programando é comum cometer um certo número de erros e suposições que fazem com que o seu programa:– Não possa ser compilado;

– Produza resultados inesperados na execução;

• Esses problemas são os bugs!

| Praticando

Simulando e detectando bugs

| Praticando

Testes automatizados

| Testes Unitários

| Testes 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 TDD;

| Testes 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 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]

| Testes Unitários

• Ferramentas:

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

– JMock: para criação de objetos e cenáriosfalsos;

| Ferramentas

JUnit

JUnit

• É um framework altamente eficaz e largamente utilizado na criação e execução de testes unitários de códigos;

http://junit.org

| Um teste com JUnit

public class HelloWorldTest {

@Test

public void testMultiplication() {

//Testando se 2*2 = 4

assertEquals ("Multiplication", 4, 2*2);

}

}

| Ferramentas

JUnit

NUnit

| NUnit

• Versão do JUnit portada para C#;

• Possui as mesmas características e segue os mesmos princípios de funcionamento e estruturação dos testes e suites de testes;

• http://www.nunit.org

| NUnit

| Um teste com NUnit

Imports NUnit.Framework

<TestFixture()> _Public Class TestaCalculadora

<Test()> _Public Sub TestaSoma()

Dim novo_valor As Decimal = Calculadora.Soma(2,2)

Assert.AreEqual(4, novo_valor)End Sub

End Class

| Ferramentas

JUnit

NUnit

TestNG

| TestNG

• Uma alternativa ao JUnit para testes unitários;

• Foi o primeiro a utilizar anotações paradefinição dos TestCases;

| TestNG

| Um teste com TestNG

import org.testng.annotations.*;

public class SimpleTest {@BeforeClasspublic void setUp() {}@Test(groups = { "calculadora" })public void somaTest() {System.out.println("soma");

}}

| Ferramentas

JUnitNUnitTestNGJMock

| JMock

• Utilizado para criar ou simular falsosobjetos/cenários;

• Alternativas:– EasyMock;

– MockObjetc;

| Aplicação a ser testada com JMock

• Uma aplicação exemplo:

public class MyServlet extends HttpServlet {private MyService myService;public void setMyService(MyService myService) {

this.myService = myService;}public void process(HttpServletRequest request, HttpServletResponse response) {String action = request.getParameter("action");//alguma coisarequest.setAttribute("model", myService.getModel());

}}

| Um teste com JMockimport org.jmock.Mock;import org.jmock.MockObjectTestCase;public class MyServletTest extends MockObjectTestCase {

private Mock mockMyService,mockRequest,mockResponse;private HttpServletRequest request;private HttpServletResponse response;private MyServlet myServlet;

protected void setUp() throws java.lang.Exception {mockMyService = mock(MyService.class);mockRequest = mock(HttpServletRequest.class);mockResponse = mock(HttpServletResponse.class);myService = (MyService) mockMyService.proxy();request = (HttpServletRequest) mockRequest.proxy();response = (HttpServletResponse) mockResponse.proxy();myServlet = new MyServlet();

}

| Um teste com JMock (continuação)

public void testUpdate() {Map parameters = new Hashtable();

mockRequest.expects(once()).method("getParameter").with(eq("action")).willreturnValue"update"));

mockRequest.expects(once()).method("setAttribute").with(eq("model"), same(parameters));

myServlet.setMyService(myService);myServlet.process(request, response);

}}

| Dúvidas?

| Praticando

• Criando seus testes;

• Ao encontrar um bug, escreva um teste;

• Corrigindo um bug;

| Testes de aceitação

| Testes de aceitação

• Testam uma história, funcionalidade ou caso de uso;

• Envolvem vários componentes do sistema ou até o sistema como um todo;

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

| Ferramentas

Selenium

| Selenium

• Ferramenta para realização de testes integrados e de aceitação;

• Usado no browser, grava todos os passos executados na aplicação diretamente no browser e os executa de forma automatizada no browser;

| Selenium

| Praticando

Integrando sempre

| Testes de integração

• Testam a integração entre componentes

• Envolvem dois ou mais componentes (classes + SGBD, classes + SGBD + webservices, várias camadas da aplicação, etc.)

• Ex. ferramentas: JUnit, DBUnit, HSQLDB

• Normalmente não é muito utilizado em TDD

| Praticando

• Todo código precisa de testes unitários;

• Todo código precisa passar nos testes unitários antes de serem lançados como produto;

| Outras Ferramentas

| JMeter

• Propósito principal para testes de carga e stress de aplicações;

• Pode ser usado para testes integrados e de aceitação;

| JMeter

| Clover

• Ferramenta para análise de cobertura dos testes existem na aplicação;

• Integrado a várias IDEs - Eclipse ;-)

• Existem diversas opções semelhantes: JCoverage, Cobertura, etc;

| Clover

| Conclusões

• Testes colaboram para o aumento da qualidade dos sistemas;

• Desenvolvedores ficam mais corajosos e confiantes ao programar;

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

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

[11]

| 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 desenvolvimento;

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

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

[11]

| Dúvidas?

| Refatoração

| Praticando

Stand-up meeting

| Stand-up meeting

• Reunião diária;

• Realizada preferencialmente de manhã;

• Toda a equipe participa, inclusive o cliente, se possível;

• Visa dois objetivos principais:– Informações;– Emoções;

| Codesmell

| Codesmell

• Codesmell ou code smell é um dos conceitos criados pelo XP;

• Um code smell é uma indicação superficial de que algo pode estar errado. Aquela mesma sensação quando você abre sua geladeira e sente um cheiro estranho;

| Codesmell

• Um bom exemplo é abrir uma classe e notar que ela está grande demais;

• Não necessariamente ela estará errada, mas é um indício de acúmulo de responsabilidades e um bom candidatoa ser refatorado;

| O que é refatorar?

| Refatoração

• O refactoring é o ato de alterar um código sem afetar a funcionalidade que ele implementa.

• É uma prática para tornar o software mais simples de ser manipulado e se utiliza fortemente dos testes descritos anteriormente para garantir que as modificações não interrompam o seu funcionamento.

| Refatoração

• Sempre existiu, mas não tinha um nome;

• Estava implícito;

• A novidade foi criar um vocabulário comum e catalogá-los.

• Assim podemos utilizar mais sistematicamente e ensinar uns aos outros;

| 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.

| 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.

| Refatoração

• Alguns indícios já possuem ampla aceitaçãopara promover uma refatoração:– Método longo;

– Classe grande;

– Lista de parâmetros longa;

– Quando o código não estiver claro;

– Melhorar a legibilidade;

– Separar a lógica existente da alteração necessária;

– Substituir um algoritmo por outro;

– Melhorar o desempenho;

| Refatorações

• Extrair Método (ExtractMethod)

• Mover Método (Move Method)

• Mover Atributo (Move Field)

• Extrair Classe (ExtractClass)

• Encapsular Atributo (Encapsulate Field)

• Renomear Método (Rename Method)

• Subir Método (Pull UpMethod)

• Subir Atributo (Pull UpField)

• Descer Método (PushDown Method)

• Descer Atributo (PushDown Field)

• Extrair Sub-classe(Extract Subclass)

• Extrair Super-classe(Extract Superclass)

| Refatoração: Benefícios

• Redução de código duplicado;

• Aumentar a simplicidade;

• Facilitar a leitura;

• Melhorar a performance;

• Manutenibilidade;

• Eficiência;

| Fatorar X Refatorar

Fatorar

• Descobrir, de modo geral, todos os componentes do sistema/solução;

Refatorar

• Achar um conjunto diferente de componentes que faça o mesmo trabalho inicial;

| Refatorar X Reescrever

Refatorar

• Não altera a funcionalidade ou conteúdo do sistema/solução;

Reescrever

• Altera a funcionalidade do sistema/solução;

| Garanta-se nos testes

Altere o código sem medo

| Garanta-se nos testes

• Antes de começar a refatoração, verifique se você tem um conjunto sólido de testes para verificar a funcionalidade do código a ser refatorado;

• Refatorações podem adicionar erros;

• Os testes vão ajudá-lo a detectar erros se eles forem criados;

| Dúvidas?

| Referê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/• [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-odeiam-testar

• [6] – Wikipedia – http://en.wikipedia.org/wiki/Test-driven_development• [7] - TDD - http://www.testdriven.com• [8] - Brod - http://www.brod.com.br• [9] – java.net - http://wiki.java.net/bin/view/People/SmellsToRefactorings• [10] – Guilherme Chapiewski - http://gc.blog.br/2007/05/09/test-driven-

development-in-a-nutshell• [11] – Guilherme Chapiewski – Palestra: Desenvolvimento Guiado por Testes

(TDD)

• Ilustações retiradas de ImproveIt, de Leandro Mello.

| Podem acordar, acabou!

• Obrigado a todos.

• Contatos:– www.portaljava.com | www.jeveaux.com

– [email protected] | [email protected]

Testes&

Refatoração

por Paulo César M. Jeveaux03/03/2008 – 05/03/2008

Esta apresentação usa a licença :

Creative Commons : de Atribuição/Uso

Não Comercial Compartilhado.

Testes e Refatoração

Technology

Transcript of Testes e Refatoração