Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Desenvolvimento Orientado a Testes (TDD) na prática com JUnit 4

Uma abordagem prática
by

Welington Veiga

on 10 October 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Desenvolvimento Orientado a Testes (TDD) na prática com JUnit 4

TDD na prática com JUnit 4
Quem sou eu...
Welington Veiga
Graduado e mesrando em Ciência da Computação pela UFJF
Coordenador de TI na AfferoLab
Certified Scrum Master
Roteiro
Testes
Você faz testes?
Mas Funciona na minha máquina!
Testes Manuais
Testar apenas o que foi alterado
não resolve o problema
Propenso a erros
Tipos de Usuário
Níveis de Acesso
Configurações
Dia do Mês
Hora
Saldo Negativo
Ano Bissexto....
Isso é muito, muito CHATO...
E vai dar errado...
É preciso testar tudo de novo,
a cada mudança no código
Consome muito tempo
Testes Automatizados
Software testando Software
Você quer dizer "código" que testa "código"...
Mas... quem vai escrever esse código???
Você!
Mas eu não sou tester,
sou DESENVOLVEDOR!!!!
Você é responsável pela qualidade
do código que você produz.
E é pra você que vão ligar
Sábado à Noite....
Automatizando Testes
"Gravar e Executar"
"Scripts de Testes"
Tipos de Testes Automatizados
Testes Unitários
Testes de Integração
Testes Funcionais
Testes de Carga

E muitos outros...
É Perda de Tempo....
Software de Qualidade
O Modelo Waterfall
40 % do tempo de desenvolvimento Testando
(cc) image by jantik on Flickr
Testes Unitários
Teste unitário é um nível de testes de software onde componentes/unidades de um software/sistema são testados individualmente. O objetivo é validar se cada unidade de software se comporta como projetado.
Definição
Garantir que, individualmente, um componente/unidade se comporte de forma correta.
Objetivo:
Exemplo
Vamos Testar o nosso código
E se mudarmos a ordem?
Ordem Decrescente
Nosso primeiro
Teste Unitário
Rodando testes unitários no Eclipse
Método testado?
R: O Que pode dar errado.
P: O que mais podemos testar?
Suspeitos:
E se mudarmos a ordem?
E se a lista contém elementos duplicados?
E se a lista contém apenas 1 elemento?
E se a lista contém números negativos?
E se a lista estiver vazia?
Ordem Crescente
Qual o problema?
E se não quebramos nada...
Vamos verificar se Funciona!
E se a lista contém elementos duplicados?
E se a lista contém apenas 1 elemento?
E se a lista contém números negativos?
Qual o problema?
Vamos testar de novo!
E se a lista estiver vazia?
Não pensamos nisso quando escrevemos
o método...
Vamos testar novamente!
Testes devem ter nomes descritivos
Testes devem ser independentes
Executados em qualquer ordem
Possuem 3 etapas
Arrange, Act, Assert
Um teste testa um aspecto
Apenas um Assert por teste.
Testes são legais.
Resumindo
Frameworks simples, baseados nos mesmos conceitos.
Desenvolvido inicialmente por Kent Back para Smalltalk (SUnit)
Erick Gama e Kent Back portaram o SUnit pra Java e deram início ao JUnit.
A partir daí surgiram CppUnit, NUnit (.NET)
Frameworks de testes unitário
xUnit
Exemplo em PHP: PHPUnit
Exemplo em C++: CppUnit
Exemplo em .NET: NUnit
Um pouco mais de JUnit
Atualmente na versão 4.10
Suportado nas principais ferramentas do mundo Java:
Eclipse, Netbeans, IntelliJ, Ant, Maven, Jenkins...
E pelos principais frameworks também...
Ampla documentação e utilização
Vários tipos de Asserts
Ciclo de Vida dos testes no JUnit
Desativando Testes temporariamente com
o @Ignore
Parametrizando Testes
Mockito
Objetivo
Dependência entre Objetos
Queremos entender e testar o comportamento de uma classe de cada vez.
Reutilização.
Precisamos encontrar rapidamente onde o código está quebrado.
Não é simples testar objetos que possuem dependências

Mas quase sempre nossos objetos dependem de outros objetos...
Injetar dependências
Criar implementações específicas de testes
Usar o Mockito para cria "Mocks" do comportamento esperado
Estratégias para tratar dependências:
Utilize Implementações falsas
A Classe Funcionário
A Classe CalculadoraSalario
Injetando dependências
Relaxa, 0 eclipse faz isso pra você o/
Exemplo:
Utilizar um "Mock"
E se a classe CalculadoraSalario:
Acessa um WebService que leva a taxa de juros do mês em consideração?
Possui uma lógica que muda de acordo com o cliente?
Demora para ser executado?
Pode ser acessado apenas no 5 dia útil do mês?
Como testar a classe Funcionário unitariamente?
Mas essas classes são realmente dependentes?
Será que conseguimos testar?
Extraia a Interface que sua classe espera
Escreva seu teste com uma implementação falsa
Mock: Objeto que Simula o objeto real de forma controlada.
Criando Mocks facilmente em Java com Mockito
Mais exemplos de mocks com Mockito
Desenvolvimento Dirigido por Testes
Test Driven Development
TDD

Mas o que é TDD?
"Descoberto" por Kent Beck em 1999, como uma prática central dentro do Extreme Programing
De onde veio?
TDD é uma prática de desenvolvimento de Software
O Ciclo de Desenvolvimento com TDD
Escreva um
teste
Execute
os Testes
"Refatore"
Execute
os Testes
Execute
os Testes
Especificar como deve se comportar o código que vamos implementar
Não criamos o código ainda, vamos definir aqui como o método vai se chamar, quais os parâmetros e como queremos que ele se comporte.
Não criamos a funcionalidade ainda!

O teste deve falhar.
Implemente
Já sabemos:
Como deverá ser a assinatura do método
Como ele deve se comportar

Agora é só implementar
APENAS
o que o teste precisa para passar!
Implementamos o comportamento esperado pelo teste.

Agora ele deve passar!
E se ele não passar?
Então vamos ver o que deu errado, corrigir e testar até que o teste passe!
Devemos desenvolver apenas o necessário para passar no teste na fase de implementação.
Caso seja possível remover alguma duplicação, ou melhoria na implementação, esta é a hora!
Se não há nada para ser melhorado, vá direto para a criação do próximo teste.
Se fizemos alguma refatoração, precisamos garantir que não quebramos nada.

Quando os testes passarem podemos assumir que tudo está okay e continuar o desenvolvimento.
DOJO
Considerações Finais
Dojo ( sítio do caminho, Dōjō) é o local onde se treinam artes marciais japonesas. Muito mais do que uma simples área, o dojo deve ser respeitado como se fosse a casa dos praticantes. Por isso, é comum ver o praticante fazendo uma reverência antes de adentrar, tal como se faz nos lares japoneses.
O que é um Dojo?
Ambiente seguro
Aprendizado contínuo
Por que "Dojo"?
Este não é um ambiente de competição, relaxe e mantenha a cabeça aberta para aprender!

Mantenha-se focado no problema, nada de discutir sobre liguagens, plataformas, frameworks ou sistemas operacionais, o Linux é muito melhor.

Ninguém deve ficar sem entender o que está acontecendo. Pergunte.

Não corra para resolver o problema, nosso objetivo é aprender com o caminho, não apenas chegar ao destino.

Divirta-se!
Manual de bom comportamento no
Dojo
Regras do Dojo
Vamos usar TDD
Baby Steps
"Programação em Par"
Todos devem entender
Estacionamento
O Problema
Requisitos:
Vamos praticar!
Como adicionar esta prática no meu trabalho?
Utilize testes para "entender" o comportamento antigo,
Crie um teste para o comportamento novo (que deve falhar)
Refatore o código para passar em todos os testes
TDD em código legado
Mas no projeto em que eu trabalho...
Técnicas para quebrar dependências
Evolução do código
Melhoria no Design
Confiança no sistema
Muitas dependências, código antigo...
Para cobrir partes antigas do sistemas, muito acopladas e difíceis testar.
Testes de Integração
Começar pela camada de visualização de sistemas legados
Reduzir o esforço com testes manuais
Aumentar a confiança no sistema

Desenvolver novas "features" usando TDD
Código novo com qualidade
Criar testes automatizados ao corrigir bugs
O fim dos "bugs chiclete"
Testes Funcionais
Integração Contínua
E se os outros desenvolvedores não rodarem os testes?
"Os testes só rodam na minha máquina..."
"Os testes demoram muito pra rodar!"
Testes Funcionais
Testes de Integração
Testes Unitários...
Ferramenta de Integração Contínua Gratuíta
Automatiza tarefas como execução de testes, "build", "deploy" e etc...
Escrito em Java, fácil de instalar, e suporta várias outras linguagens e tecnologias.
Jenkins
Problemas de uma equipe que mantém
testes automatizados....
Um pouco do Jenkins
welington.veiga@gmail.com
Obrigado
Precisamos desconfiar!
Você está mesmo testando isto certo?
A lógica por trás do valor retornado pelo CalculaSalario nos testes de Funcionario não importa.

Haverá uma classe de testes para cada implementação de ClaculaSalario
Nossa classe de teste testa
apenas a classe Funcionario!
Utilizando Mockito é bem mais fácil !
Hoje o TDD se justifica independentemente do XP
Qual a Ideia ?
Como nós desenvolvemos sem TDD
Design
Implementação
Testes
Testes
Linha Ideal de Desenvolvimento
E qual é problema com esta abordagem?
Momento em que um erro é cometido
tempo
Esforço para corrigir o erro
O ideal é encontrarmos o erro o mais rápido possível!
Implementação
Design
Como desenvolvemos com TDD
Criamos um teste para assegurar que aquele comportamento funciona antes dele existir

É muito mais barato resolver um bug neste momento
Temos Feedback rapidamente!
Mas está é só uma das vantagens...
about.me/welingtonveiga
O que ganhamos TDD?
Código Testável Por Definição
TDD melhora o "Design"
Melhoria Continua
Design Incremental
Códigos pequenos e com pouca responsabilidade

Poucos pontos de indireção

Reaproveitamento de código

Facilitade em realizar alterações na arquitetura coberto por testes
Testes exigem um bom design
Foco no essêncial
E você?
Mensagem descritiva
Resultado esperado
Resultado obtido
Full transcript