A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Core business solutions. Ambiente de Desenvolvimento e Execução de Testes Automáticos para Times Scrum Danival Taffarel Calegari MATERA Systems Alexandre.

Apresentações semelhantes


Apresentação em tema: "Core business solutions. Ambiente de Desenvolvimento e Execução de Testes Automáticos para Times Scrum Danival Taffarel Calegari MATERA Systems Alexandre."— Transcrição da apresentação:

1 core business solutions

2 Ambiente de Desenvolvimento e Execução de Testes Automáticos para Times Scrum Danival Taffarel Calegari MATERA Systems Alexandre de Souza Pinto MATERA Systems

3 Sobre os palestrantes Danival Taffarel Calegari Mestre em Ciência da Computação pela UNICAMP. Trabalha com tecnologia Java há mais de 10 anos. Atua há mais de 3 anos com líder técnico na MATERA Systems. Atua há mais de 5 anos como instrutor da Globalcode. Palestras em eventos nacionais e internacionais: JustJava, TCD, JavaOne. Certificações: SCJP, SCWCD, SCBCD. Alexandre de Souza Pinto Engenheiro de Computação pela Unicamp, com mestrado na mesma Universidade e MBA pela Fundação Dom Cabral Trabalha na MATERA Systems há 10 anos como gerente de equipes de desenvolvimento Atualmente, gerencia a área de desenvolvimento da suíte MATERA Gestão Empresarial (ERP)

4 Agenda Introdução Histórico da automação de testes na MATERA Princípios para uma boa automação de testes Facilitando a escrita dos testes: DSL Facilitando a execução dos testes Ambientes de integração contínua Estudo de caso: evolução dos produtos da MATERA

5 Introdução Processos ágeis pregam ciclos de desenvolvimento curtos com entregas frequentes. No SCRUM deve-se fazer uma entrega ao final de cada sprint. A cada nova entrega deve-se garantir que as funcionalidades previamente prontas continuam funcionando. O esforço de testes de regressão aumenta significativamente. Quando o cliente começa a utilizar o software, ele identifica muitas mudanças. O desenvolvedor pode levar um tempo considerável para conseguir executar uma funcionalidade novamente para fazer as alterações. A automação de testes tende a resolver estes problemas e aumentar as chances de sucesso de projetos SCRUM!

6 Automação de testes na MATERA 2007: primeiro contato com o framework Scrum e técnicas de desenvolvimento ágil Projeto do tipo staff augmentation com cliente dos EUA Sprints, Testes automáticos (Junit, JWebUnit), Integração Contínua : primeiro projeto tailor-made da MATERA, utilizando técnicas ágeis e conceito de sprints Selenium, DBUnit, TestNG, Team City Apesar do esforço inicial para construir o ambiente de testes automático, já foi possível perceber ganhos de produtividade, principalmente ao realizar refactorings de código 2009-atual: evoluções do ambiente de testes Uso de máquinas virtuais, bases de dados locais, DSL's Novos projetos tem como regra o uso de mecanismos de automação de testes

7 Princípios de uma boa automação de testes Os testes automatizados devem ser fáceis de escrever Os desenvolvedores devem achar que escrever os testes automatizados é mais fácil que fazê-los na mão. Os testes automatizados devem ser fáceis de executar O ambiente de execução de testes deve ser o mais simples de se montar o possível. Auto contido Cada desenvolvedor deve ser capaz de executar os testes de forma independente e sempre que julgar necessário. Os testes devem ser executados frequentemente Idealmente deve-se ter um ambiente de integração contínua. Devem ser mantidos atualizados

8 Facilitando a escrita de testes DSL – Domain Specific Language Desenvolvimento de uma linguagem para escrever os testes. A linguagem deve estar mais próxima ao negócio do que da tecnologia. Quanto mais fácil a DSL de utilizar, maior a chance dela ser utilizada! DSL interna (API) x DSL externa (Parser) DSLs internas são mais fácil de escrever, possuem suporte de ferramentas e dão boa fluência a quem conhece a tecnologia. DSLs externas tem menos limitações de tecnologia, agregam mais significado por linha de código e exigem menos conhecimentos técnicos de quem escreve os testes.

9 Exemplos de DSL Interna : Conta c1 = dsl.novaConta().numero("112233").saldo(4500.0); Conta c2 = dsl.novaConta().numero("445566").saldo(8500.0); dsl.transferir(c1, c2, ); c1.verificarSaldo(3500.0); c2.verificarSaldo(9500.0); Externa: para conta saldo para conta saldo transferir valor 1000 de para verificar saldo igual verificar saldo igual

10 Passos para a construção de DSL para testes Montagem de uma infraestrutura básica para execução dos procedimentos e verificação de resultados. Como executar um batch no servidor de forma isolada? Como o código de testes vai executar um SQL para verificar os resultados? Como abrir o browser, fazer login, clicar em um botão? Para testes em Java, disponibilizar uma classe base abstrata para ser estendida. Fazer uma DSL para cada funcionalidade. É possível fazer reaproveitamento entre funcionalidades similares. Testar a funcionalidade.

11 Dicas para uma boa DSL de testes Uso do padrão Builder dsl.novaConta().numero("112233").saldo(4500.0); Valores default ou gerados automaticamente Ex. todas as contas geradas pela DSL pertencem a uma mesma agência gerada automaticamente, a menos que se diga o contrário. Para verificações de múltiplos valores, criar verificadores.

12 Exemplo de teste usando public void testAllocationForOneGroup() { dsl.populateMasterAccount(groupCode, "FUNDO A").populateClientAccount(clientCode, "FUNDO B", groupCode); dsl.openMovement(tradeDate); TestContract contract = dsl.newContract().tradeDate(tradeDate).groupCode(groupCode).marketType("FUT").businessCode("DOLJ11").product("DOL").maturityCode("J11").nature(Nature.BUY).price(" ").quantity(1000L); dsl.populateContracts(contract); dsl.runAllocation(); dsl.assertAllocationExecuted(1); ProcedureVerifier verifier = dsl.allocationProcedureVerifier(); verifier.addVerification(contract).clientCode(clientCode).quantity(1000).tradeDate(tradeDate); procedureVerifier.assertValues(); }

13 Facilitando a execução dos testes DSLs internas permitem boa integração com ferramentas de desenvolvimento. Um teste feito com o JUnit ou TestNG permite a execução apenas com um clique do botão direito sobre a classe de testes. Criar classe base de testes com scripts que montam o ambiente para execução dos testes. Ex. ferramenta Cargo para configurar, iniciar e parar o servidor. Carga automática de uma massa de dados. Deve-se evitar testes demorados. Fazer um profile com testes mais básicos para o dia a dia e um completo para integração contínua. Elaborar um roteiro para montar o ambiente de testes. Deve-se investir mais em scripts do que em roteiros!

14 Exemplo: execução de teste no Eclipse

15 Criando testes auto contidos Cada desenvolvedor deve ter um banco de dados exclusivo. Cada um schema por desenvolvedor. Quando possível, criar máquinas virtuais (VMs) para executar na máquina do desenvolvedor. A infraestrutura de testes deve endereçar problemas relativos a configurações de ambiente: Data do sistema. Sistemas externos. Execução concorrente de batches.

16 Executando os testes com frequencia Testes que não são executados não tem serventia. Dependendo do negócio, o tempo de execução dos testes tende a ser grande. Criar profile para execução de testes mais simples pelos desenvoledores. Ferramentas automatizadas para execução dos testes sempre que houver um commit no repositório de código ou periodicamente. TeamCity Hudson Apache Continuum Bamboo Cruise Control

17 Ambiente do TeamCity para IC

18 Testes automáticos – Evolução de Produtos

19 Dezenas de produtos Alguns deles com anos Tecnologias Centura, Oracle Forms, PL/SQL, Java Liberações frequentes (~45 dias) de novas versões em virtude de legislações e customizações. Experiência em projetos sugere benefícios em desenvolver testes automáticos também para os produtos mas como justificar o investimento considerando um código-fonte legado com centenas de milhares de linhas?

20 Testes automáticos – Evolução de Produtos Abordagem baby steps (início: março 2011) Piloto: Sistema de Contas a Pagar Desenvolvimento da DSL: foco nas entidades principais do sistema (Títulos, por exemplo) e operações críticas (Baixas de títulos, por exemplo) Objetivo: garantir a sanidade do sistema nas suas operações principais (minimizar efeitos colaterais em funcionalidades críticas) Adaptação do ambiente de testes dos projetos (voltado para a plataforma Java) para uma plataforma database centric DB Test: framework desenvolvido para suporte aos testes automáticos Máquina virtual: Base local Oracle Teste implementado em Java (DSL abstrai objetos do BD, DML's) Tratamento de parâmetros default, Sysdate Aproveitamos como fixture os dados da base local (VM), com a aplicação dos scripts de BD mais recentes Team City para integração contínua

21 Testes automáticos – Evolução de Produtos Status Integração contínua: check-out do código no CVS, VM (inicialização, atualização de snapshots), aplicação dos objetos no BD, execução dos testes Builds remotas: servidor exclusivo Cerca de 50 casos de teste para o sistema de Contas a Pagar Próximos passos Extensão da DSL do sistema-piloto Utilização do mecanismo em outros produtos Otimizar infraestrutura para execução mais rápida dos testes Pesquisar ferramentas de avaliação de cobertura de código Implantação de um modelo de bug fix, que irá proporcionar mais agilidade na liberação de patches, aproveitando também o ambiente de testes automáticos

22 Ambiente de Desenvolvimento e Execução de Testes Automáticos para Times Scrum Danival Taffarel Calegari MATERA Systems Alexandre de Souza Pinto MATERA Systems


Carregar ppt "Core business solutions. Ambiente de Desenvolvimento e Execução de Testes Automáticos para Times Scrum Danival Taffarel Calegari MATERA Systems Alexandre."

Apresentações semelhantes


Anúncios Google