Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
Implementando Integração Contínua para Melhorar Qualidade de Software
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