Testes e Refatoração

Slide 1: Testes & Refatoração

Slide 2: Testes & Refatoração por Paulo César M. Jeveaux 03/03/2008 – 05/03/2008

Slide 3: | 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;

Slide 4: | Testes • Planejamento: User • Corrigindo um bug stories • Testes de aceitação • O que é um bug • Praticando: Integrando • Como simular e detectar sempre um bug • Praticando: Todo código • Praticando: Testes precisa de testes automatizados unitários. • Testes unitários • Praticando: Todo código • Ferramentas: JUnit e precisa passar nos testes TestNG unitários antes de serem • Criando o seu teste lançados como produto. • Praticando: Ao detectar • Retrospectiva um bug, escreva um teste

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

Slide 6: | Introdução Desenvolvimento de software

Slide 8: | Introdução Desenvolvimento de software Falhas de Software

Slide 9: | Falhas de Software • Mais de 1/3 das falhas poderiam ser evitadas com testes; [1] • Cerca de 50% das falhas só são descobertas em produção; [1]

Slide 10: | Introdução Desenvolvimento de software Falhas de Software Falhas custam caro

Slide 11: | 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]

Slide 12: | Introdução Desenvolvimento de software Falhas de Software Falhas custam caro Testes não evitam falhas

Slide 14: | Introdução Desenvolvimento de software Falhas de Software Falhas custam caro Testes não evitam falhas Testes identificam as falhas antes delas acontecerem

Slide 16: | O que são testes?

Slide 17: | 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;

Slide 18: | O que são testes? • São pontuais; • São previsíveis; • São finitos; • São (ou deveriam ser) simples;

Slide 19: | 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;

Slide 20: | O que são testes? White Box

Slide 21: | Caixa branca • Testes de unidade de código; • Testam parte da solução; • São escritos e mantidos pelo programador e devem estar sempre atualizados;

Slide 22: | 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.

Slide 23: | O que são testes? White Box Black Box

Slide 24: | Caixa preta • Testes funcionais e de aceitação; • Testes de integração; • Testam a solução completa;

Slide 25: | Cobertura de testes

Slide 26: Cobertura dos testes Resultado esperado Trecho alterado com alteração: OK Reflexo da alteração Erro #1 Reflexo da alteração Erro #2 Reflexo da alteração BUG Reflexo da alteração Inesperado

Slide 27: | Cobertura dos testes Sem cobertura Com cobertura • Novo release = códigos sem testes; • Não há segurança de que as alterações não irão impactar em outros pontos da aplicação; • Problemas, muitos problemas;

Slide 28: | Cobertura 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;

Slide 29: | Cobertura dos testes • Aplicações cobertas por bons testes propiciam: – Facilidade de manutenção; – Facilidade para inclusão de novos membros no time de desenvolvimento; – Menos problemas e redução de custos em manutenções; – Telefone silencioso nas madrugadas!

Slide 30: | Testes são necessários • Você precisa verificar o código, sempre; • Você precisa garantir que os requisitos estão implementados (e corretos); • Você precisa ter segurança para realizar alterações;

Slide 31: | Testes são necessários • Você precisa testar rápido para entregar rápido; • Você aumenta e garante a qualidade da sua solução com testes; • Você precisa ser criativo para explorar o máximo possível com seus testes, não use testes mentirosos;

Slide 32: | Você confia no que faz?

Slide 34: | Garanta o que você faz • Cliente: – Isso aqui não está funcionando! • Programador: – Mas como!? Na minha máquina estava funcionando até ontem.

Slide 35: | Garanta o seu trabalho, seja profissional Errado! Realidade! • Num mundo • O cliente não quer capitalizado não há saber se X virou Y. Ele tempo para testes; quer que o problema não aconteça e se • O cliente não quer acontecer que seja saber como é feito, ele corrigido rapidamente; quer que funcione • Não se consegue qualidade e confiabilidade sem [4] testes;

Slide 37: | Test-Driven Development

Slide 38: | TDD refatore Escreva código Escreva um que passe Teste no teste

Slide 39: | Dúvidas?

Slide 40: | XP Extreme Programing

Slide 42: | Extreme Programming • Metodologia de desenvolvimento de software; • Originada nos Estados Unidos (anos 90);

Slide 43: | 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ípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.

Slide 44: | Extreme Programming Valores Princípios • Comunicação • Auto-semelhança • Coragem • Benefício Mútuo • Feedback • Diversidade | Economia • Respeito • Falha | Fluidez • Simplicidade • Humanismo | Melhoria • Oportunidade • Passos de Bebê • Qualidade • Redundância | Reflexão • Responsabilidade Aceita

Slide 45: | Extreme Programming Papéis Práticas • Analistas de Teste • Ambiente Informativo • Arquitetos • Build de Dez Minutos • Designers de Interação • Ciclo: semana/trimestre • Executivos • TDD • Gerentes de Projeto • Código Coletivo • Gerentes de Produto • Continuidade da Equipe • Programadores • Escopo Negociável • Recursos Humanos • Reunião em Pé • Redatores Técnicos • Refatoração • Usuários • Metáfora e muitos etc

Slide 46: | Histórias User Stories

Slide 47: | 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]

Slide 48: | Histórias

Slide 49: | 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.

Slide 50: | Histórias • Cards: As histórias são • Confirmation: Depois sempre escritas em das funcionalidades cartões ou post-its. terem sido discutidas e • Conversation: A história escritas nos cartões, o escrita no cartão serve cliente define (implícita como um lembrete da ou explicitamente) uma conversa entre cliente e maneira de validar esse desenvolvedor; pedido. Geralmente essa confirmação é feita com testes de aceitação.

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

Slide 52: | Histórias • Independent: • Estimatable: Os Histórias devem ser desenvolvedores independentes uma devem ser capazes das outras. de estimar o • Negotiable: Histórias tamanhos das não são contratos. histórias . • Valuable: Histórias • Small: Tamanho é devem agregar valor documento. para o cliente. • Testable: Histórias devem ser possíveis de serem testadas.

Slide 53: | Dúvidas?

Slide 54: | Bug O que é?

Slide 56: | Bugs • Podem ser as baratinhas nas válvulas do Eniac; • Os insetos no vidro do carro; • E milhões de outros problemas que somente os usuários irão encontrar;

Slide 57: | 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;

Slide 58: | 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.

Slide 59: | Bug Como simular e detectar

Slide 60: | 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!

Slide 61: | Praticando Simulando e detectando bugs

Slide 62: | Praticando Testes automatizados

Slide 63: | Testes Unitários

Slide 64: | 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;

Slide 65: | 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]

Slide 66: | Testes Unitários • Ferramentas: – JUnit/NUnit e TestNG: para testes unitários; – JMock: para criação de objetos e cenários falsos;

Slide 67: | Ferramentas JUnit

Slide 68: JUnit • É um framework altamente eficaz e largamente utilizado na criação e execução de testes unitários de códigos; http://junit.org

Slide 69: | Um teste com JUnit public class HelloWorldTest { @Test public void testMultiplication() { //Testando se 2*2 = 4 assertEquals ("Multiplication", 4, 2*2); } }

Slide 70: | Ferramentas JUnit NUnit

Slide 71: | 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

Slide 72: | NUnit

Slide 73: | 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

Slide 74: | Ferramentas JUnit NUnit TestNG

Slide 75: | TestNG • Uma alternativa ao JUnit para testes unitários; • Foi o primeiro a utilizar anotações para definição dos TestCases;

Slide 76: | TestNG

Slide 77: | Um teste com TestNG import org.testng.annotations.*; public class SimpleTest { @BeforeClass public void setUp() { } @Test(groups = { "calculadora" }) public void somaTest() { System.out.println("soma"); } }

Slide 78: | Ferramentas JUnit NUnit TestNG JMock

Slide 79: | JMock • Utilizado para criar ou simular falsos objetos/cenários; • Alternativas: – EasyMock; – MockObjetc;

Slide 80: | 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 coisa request.setAttribute("model", myService.getModel()); } }

Slide 81: | Um teste com JMock import 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(); }

Slide 82: | 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); } }

Slide 83: | Dúvidas?

Slide 84: | Praticando • Criando seus testes; • Ao encontrar um bug, escreva um teste; • Corrigindo um bug;

Slide 85: | Testes de aceitação

Slide 86: | 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;

Slide 87: | Ferramentas Selenium

Slide 88: | 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;

Slide 89: | Selenium

Slide 90: | Praticando Integrando sempre

Slide 91: | 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

Slide 92: | 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;

Slide 93: | Outras Ferramentas

Slide 94: | JMeter • Propósito principal para testes de carga e stress de aplicações; • Pode ser usado para testes integrados e de aceitação;

Slide 95: | JMeter

Slide 96: | 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;

Slide 98: | Clover

Slide 99: | 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]

Slide 100: | 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]

Slide 101: | Dúvidas?

Slide 102: | Refatoração

Slide 104: | Praticando Stand-up meeting

Slide 106: | 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;

Slide 107: | Codesmell

Slide 108: | 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;

Slide 109: | 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 candidato a ser refatorado;

Slide 110: | O que é refatorar?

Slide 111: | 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.

Slide 112: | 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;

Slide 113: | 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.

Slide 114: | 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.

Slide 115: | Refatoração • Alguns indícios já possuem ampla aceitação para 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;

Slide 116: | Refatorações • Extrair Método (Extract • Subir Método (Pull Up Method) Method) • Mover Método (Move • Subir Atributo (Pull Up Method) Field) • Mover Atributo (Move • Descer Método (Push Field) Down Method) • Extrair Classe (Extract • Descer Atributo (Push Class) Down Field) • Encapsular Atributo • Extrair Sub-classe (Encapsulate Field) (Extract Subclass) • Renomear Método • Extrair Super-classe (Rename Method) (Extract Superclass)

Slide 117: | Refatoração: Benefícios • Redução de código duplicado; • Aumentar a simplicidade; • Facilitar a leitura; • Melhorar a performance; • Manutenibilidade; • Eficiência;

Slide 118: | Fatorar X Refatorar Fatorar Refatorar • Descobrir, de modo • Achar um conjunto geral, todos os diferente de componentes do componentes que faça o sistema/solução; mesmo trabalho inicial;

Slide 119: | Refatorar X Reescrever Refatorar Reescrever • Não altera a • Altera a funcionalidade funcionalidade ou do sistema/solução; conteúdo do sistema/solução;

Slide 120: | Garanta-se nos testes Altere o código sem medo

Slide 121: | 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;

Slide 122: | Dúvidas?

Slide 123: | 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.

Slide 124: | Podem acordar, acabou! • Obrigado a todos. • Contatos: – www.portaljava.com | www.jeveaux.com – jeveaux@portaljava.com | paulo@jeveaux.com

Slide 125: Testes & Refatoração Esta apresentação usa a licença : Creative Commons : de Atribuição/Uso por Paulo César M. Jeveaux Não Comercial Compartilhado. 03/03/2008 – 05/03/2008