Upload
paulo-cesar-m-jeveaux
View
1.653
Download
3
Embed Size (px)
Citation preview
| 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
| Falhas de Software
• Mais de 1/3 dasfalhas poderiam ser evitadas com testes; [1]
• Cerca de 50% dasfalhas só sãodescobertas emprodução; [1]
| 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
Desenvolvimento de software
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;
| O que são testes?
• São pontuais;
• São previsíveis;
• São finitos;
• São (ou deveriam ser) simples;
| O que são testes?
• 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;
| 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.
| Caixa preta
• Testes funcionais e de aceitação;
• Testes de integração;
• Testam a solução completa;
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
| Cobertura dos testes
• 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;
| Cobertura dos testes
• 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;
| 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]
| Extreme Programming
• Metodologia de desenvolvimento de software;
• Originada nos Estados Unidos (anos 90);
| Extreme Programming
• 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.
| Extreme Programming
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
| Extreme Programming
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
• 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
• 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.
| 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
• 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!
| 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;
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);
}
}
| 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
| 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
| TestNG
• Uma alternativa ao JUnit para testes unitários;
• Foi o primeiro a utilizar anotações paradefinição dos TestCases;
| Um teste com TestNG
import org.testng.annotations.*;
public class SimpleTest {@BeforeClasspublic void setUp() {}@Test(groups = { "calculadora" })public void somaTest() {System.out.println("soma");
}}
| 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);
}}
| 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;
| 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;
| 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;
| JMeter
• Propósito principal para testes de carga e stress de aplicações;
• Pode ser usado para testes integrados e de aceitação;
| 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;
| 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]
| 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 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;
| 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
• 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;
| 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