core business solutions

Ambiente de Desenvolvimento e Execução de Testes Automáticos

para Times Scrum

Danival Taffarel CalegariMATERA Systems

Alexandre de Souza PintoMATERA Systems

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)

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

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!

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

2007-2008: 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

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

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.

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, 1000.0);

c1.verificarSaldo(3500.0);

c2.verificarSaldo(9500.0);

Externa:

para conta 112233 saldo 4500.0

para conta 445566 saldo 8500.0

transferir valor 1000 de 112233 para 445566

verificar saldo 112233 igual 3500.0

verificar saldo 445566 igual 9500.0

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.

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

Exemplo de teste usando DSL

@Testpublic 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("1700.119").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();}

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!

Exemplo: execução de teste no Eclipse

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.

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

Ambiente do TeamCity para IC

Testes automáticos – Evolução de Produtos

Testes automáticos – Evolução de Produtos

Dezenas de produtos Alguns deles com 10-15 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?

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

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

Ambiente de Desenvolvimento e Execução de Testes Automáticos

para Times Scrum

Danival Taffarel CalegariMATERA Systems

Alexandre de Souza PintoMATERA Systems