Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Simtecce 2011 Integracao Continua
1. Aplicação de Integração Contínua na
melhoria da qualidade do
desenvolvimento de software
Prof. Msc Rogério Augusto Rondini
rarondini.paradygma@gmail.com
1
2. Qualidade
● Visão simplista
– Para o cliente → o sistema funciona ?
– Para o fornecedor → deu lucro ?
– Para o programador → o código
compila ??
● Uma definição de qualidade
– Convergência entre requisitos
completos, código correto e mínimo
de defeitos
2
3. Qualidade
É preciso mudar a forma de se
trabalhar
● Programar, apesar de divertido, não é
brincadeira
● Se as falhas são inevitáveis, melhor
antecipá-las
● Quanto maior o retrabalho, maior o stress
(e seu final de semana já era...)
● Fatores críticos: Automação, Testes,
Monitoração Constante
3
4. Qualidade
Nosso Foco
Nosso Foco
Convergência – requisitos completos, código correto e mínimo de defeitos.
4
5. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
5
6. Distribuição de
Software
● Parte do processo de desenvolvimento que
engloba
– Empacotamento
– Testes
– Validações
– Entrega ou Implantação (deployment)
Em desenvolvimento profissional, não
basta o desenvolvedor exportar o .WAR
pelo eclipse.
6
7. Distribuição de
Software
● Tarefa algumas vezes “esquecida“ ou de
pouca importância no processo de
desenvolvimento
● Quando mal organizada, pode causar
inúmeros problemas
– Falhas na execução
– Atrasos e Retrabalho...
Utilizando um procedimento
automatizado, a tendência é minizar os
problemas
7
8. Distribuição de
Software
● Antes, é preciso entender...
– Build
● Versão empacotada do sistema
● Pode ser incompleta, mas deve
ser estável (e.g Build
Snapshot )
– Release
● Associadas a marcos do projeto
● Internas ou Externas
8
9. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
9
10. Automação
de Build
● Build manual é um processo demorado e
propenso a erros
– Dificuldade em saber a versão correta
de um artefato
– Dificuldade para gerenciamento de
dependências
● Necessidade de uso de ferramentas
apropriadas para automação
– Ex: Maven
10
11. Maven
● Acumulador de conhecimento
● Objetivos
– Distribuição de Software
– Automação de atividades repetivtivas
– Gerenciamento de Dependência
● Aplicações JavaEE são formadas
por diversos componentes
(.jar)
11
12. Maven
● Exemplo de dependência – Spring 3.0.5
– spring-core-3.0.5.jar depende de
commons-login-1.1.1.jar
●
● spring-asm.jar
● Algum desses componentes podem depender
de outros
● Adicionalmente, tem o controle da versão do
componente
Árvore de dependências aumenta com a
complexidade do projeto
12
14. Maven
● Repositórios
– Local
Diretório padrão
Uma pasta de componente
(groupId = aspectjrt)
Versão do componente
(version = 1.5.3)
componente
(artifactId)
14
17. Maven
● Permite integração com servidores de
aplicação através de plugins específicos
– Jboss → jboss-maven-plugin
http://mojo.codehaus.org/jboss-maven-
– Tomcat → tomcat-maven-plugin
http://mojo.codehaus.org/tomcat-maven
– Websphere → was6-maven-plugin
http://mojo.codehaus.org/was6-maven-
– Weblogic → weblogic-maven-plugin
http://mojo.codehaus.org/weblogic-mav
17
18. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
18
19. Controle de Versão
● Cenários típicos de ambiente sem controle
– Sim, fui eu que alterei o código, mas já
faz tanto tempo que nem me lembro o
motivo.
– Eu alterei este programa, mas esta já
era a vigésima alteração no mesmo
programa, e este erro que apareceu
não é meu.
– Eu alterei ontem, mas não sabia que
você também estava alterando. Qual a
última versão ?
19
20. Controle de Versão
● Sistema para armazenar artefatos de
projeto, tipicamente documentação e
código fonte
● Armazenamento centralizado
● Responsabilidade de manter histórico de
todas as alterações realizadas
● Responsabilidade de controlar alterações
20
21. Controle de Versão
● Subversion
– Integração com Eclipse
– Histórico de alterações
– Operações
● Checkin e Checkout
● Merge
● Branching e Tagging
21
24. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
24
25. Análise de Código
● Atividade que visa garantir
– Aderência aos padrões definidos pela
empresa
– Boas práticas de desenvolvimento
● Ferramentas
– PMD → procura por potenciais
defeitos
– Checkstyle → ajuda a manter padrões
estabelecidos
25
26. Análise de Código
● Tanto PMD quanto Checkstyle podem ser
– configuradas no Eclipse (ou
Netbeans)
– incorporadas ao processo de
automação de build (e.g Maven)
26
27. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
27
28. Teste Unitário
● Implementado com base no menor
elemento testável do software
● Testa estrutura interna (abordagem caixa
branca) e comportamentos observáveis
(abordagem caixa preta)
● Deve-se buscar a maior cobertura possível
● Objetivos
– Isolar partes do sistema
– Mostrar que partes isoladas
funcionam
28
29. Teste Unitário
● Benefícios
– Facilita manutenção
● Validação das mudanças
● Garantia de funcionamenot pós
alteração
– Simplifica integração entre
componentes
● Uso de ferramentas para execução de
testes, e.g Junit e Cobertura
29
30. Teste Unitário
● Exemplo
public class TestCadastrarEscala extends TestCase {
public void testValidarHorarioTrabalhoHorarioValido()
throws Exception{
Horario hr = new Horario(1,"08:00","17:00");
boolean resultado = hr.validarHorarioTrabalho();
assertTrue("Resultado esperado deveria ser TRUE, pois
os dados informados correspondem a 9 horas de
trabalho",resultado);
}
}
Maven irá executar os testes
automaticamente, basta identificar as classes
de teste em uma pasta “test“, e seguir o
padrão JUnit
30
31. Teste Unitário
● É possível utilizar ferramenta para medir a
cobertura dos testes
– Quanto do código realmente está
sendo coberto pelos testes
unitários
● Em termos de métodos
● Linhas de código
● Branchs (if/else, switch/case...)
– Abordagem caixa branca
– Complexidade ciclomática
31
32. Teste Unitário
● Demonstração
– Classe Escala com um método
inserirHorario
● Regra: total horas mês <= 160
– Classe Horario com um método
validarHorario
● Regra: total horas dia <= 12
Os testes unitários devem prever todas as
situações, válidas e inválidas
32
34. Agenda
● Distribuição de Software
● Automação de Build → Maven
● Controle de Versão → SVN
● Análise de código → PMD e Checkstyle
● Testes Unitários → Junit e Cobertura
● Integração Contínua → Hudson
34
35. Integração
Contínua
“Prática de desenvolvimento de software
onde os membros integram seu trabalho
frequentemente. Cada integração é
verificada por um processo automatizado
para detectar erros o mais rápido
possível.”
Martin Fowler
35
36. Integração
Contínua
● Estratégia aplicada ao controle de
qualidade de software
– Mudança de paradiga onde o controle
de qualidade passa a ser aplicado
durante o desenvolvimento, e não
apenas após a conclusão do
desenvolvimento
36
37. Integração
Contínua
● Desenvolvimento Iterativo e Incremental
– Alterações frequentes
37
38. Integração
Contínua
● Tarefas distribuídas
entre a equipe CR-0002 – Compra
(erro ao calcular valor total itens)
– Código
compartilhado
entre os
desenvolvedores Efetuar pgto boteto
– Maior
probabilidade de Efetuar pgto cartão
falhas
CR-0001
Cadastro de produto
38
39. Integração
Contínua
● Teve início com o desenvolvimento ágil de
software
– Uma das práticas do XP (eXtreme
Programming)
Execução da Integração Contínua
39
40. Integração
Contínua
● Automação
– Compilação
– Análise de Código
– Geração de build (empacotamento)
– Execução de testes
● Unitários
● Cobertura
● …
● Relatórios
40
41. Integração
Contínua
Repositório Máquina de
Central Integração
Download da
última versão Tarefas agendadas
do código-fonte
Feedback
Commit diário - métricas de cobertura de teste
- relatórios de falhas
- relatórios de compilação
...
...
Equipe do projeto
Efetuar pgto Efetuar pgto CR - 0001 CR - 0002
cartão boleto
41
42. Integração
Contínua
● Algumas práticas recomendadas
– Cultura de testes deve fazer parte da
equipe de desenvolvimento
– Repositório central de código
– Manter uma build auto-testável
– Checkin frequente (diário)
42
43. Integração
Contínua
● Apesar de ter sido criada para
atender a uma necessidade das
metodologias ágeis de
desenvolvimento (principalmente
XP), vem sendo adotada também em
empresas que não utilizam
metodologias ágeis.
43
44. Integração
Contínua
● Pontos-Chave
– Automação no processo de geração de
build
– Garantia de qualidade de código
desenvolvido
– Atendimento aos padrões de
desenvolvimento
– Cobertura de testes
44
45. Integração
Contínua
● Algumas vantagens
– Problemas são encontrados e corrigidos
frequentemente, evitando “last-minute
chaos“ ao se aproximar da data de
entrega
– Constante disponibilidade de um pacote
de software para teste, demonstração
ou entrega
– Medição constante da qualidade do
desenvolvimento
45
46. Não se limite a fazer apenas o
que lhe pedem: estude,
pense, proponha mudanças.
Sugestão de Leitura:
Fearless Change: Patterns for introduce new ideas
Linda Rising
Prof. Msc Rogério Augusto Rondini
rarondini.paradygma@gmail.com
46
47. Referências
● Ferramentas
– CruiseControl (http://cruisecontrol.sourceforge.net/)
– Hudson (http://hudson-ci.org/)
– Continuum (http://continuum.apache.org)
– Microsoft TeamFoudationBuild / Visual
Studio Team System
– Maven (http://maven.apache.org/)
– Junit (http://www.junit.org/)
– PMD (http://pmd.sourceforge.net/)
– Checkstyle (http://checkstyle.sourceforge.net/)
47