Mantendo a Qualidade dos Códigos de Teste
Upcoming SlideShare
Loading in...5
×
 

Mantendo a Qualidade dos Códigos de Teste

on

  • 1,262 views

Apresentação feita no Agile Brazil 2011, em Fortaleza, por Maurício Eduardo Szabo ...

Apresentação feita no Agile Brazil 2011, em Fortaleza, por Maurício Eduardo Szabo

Recomendo baixar a apresentação, a versão do slideshare não apresenta algumas animações que são essenciais para o entendimento

Statistics

Views

Total Views
1,262
Views on SlideShare
1,151
Embed Views
111

Actions

Likes
0
Downloads
15
Comments
1

2 Embeds 111

http://www.techgig.com 88
http://10.150.200.57 23

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mantendo a Qualidade dos Códigos de Teste Mantendo a Qualidade dos Códigos de Teste Presentation Transcript

  • AgileBrazil 2011 Melhorando a Qualidade dos Códigos de Teste Maurício Eduardo Szabo [email_address] @mauricio_szabo http://mauricioszabo.wordpress.com http://github.com/mauricioszabo/AgileBrazil2011
  • about:me
    • Programador Ruby, Java, Python, Scala, C/C++, etc...
    • Scrum Master
    • Test-Addicted
    • Clean-Code Addicted
    • Enfim...
  • Intro
    • Agilidade, mudanças contínuas, requisitos mutantes
      • Garantia de estabilidade – testes
      • ”Dedo duro” - sempre saber o estado de seu sistema
      • Confiabilidade no código, acabar com o ”medo de mudar”
      • Requisitos mudam == testes mudam
  • Intro – Testes se Pagam
    • Testes demoram para ser escritos?
  • Mudança - Exemplo
    • Parsing de HTML
      • Quero uma lista de todos os homens na página
      • Para saber se o Ariovaldo está aparecendo na listagem de homens
  • Minha Abordagem: BDD
    • Testes x Comportamento
      • Deixa eu ver se isso funciona...
        • assert(this, works());
      • Deixa eu ver se está fazendo isso mesmo...
        • assertThat(this, isDoing(right));
    • Assert x Should
      • (Assert x Matcher)
    • Big Picture – Small Picture – Smaller Picture – Unit Test
  • Primeiros Exemplos
    • Situação: elemento está verde?
  • Mudança de ”Estilo”
    • Situação: salário válido deve calcular IRPF
  • (Evitar Cometer) Erros Comuns
  • JAMAIS!!!
  • Oops... Certos testes não dizem NADA Certos testes dizem DEMAIS
  • Framework de Testes O que usar, como usar, por que usar?
  • Framework de Testes
    • Test/Unit, JBehave, RSpec, ScalaTest, JUnit, Jasminne, JSpec...
    • Mocks: Mocha, FlexMock, Mockito, JMock, etc...
    • Escolha corretamente: Um framework de testes:
      • Deve ser extensível
      • Deve ser flexível
    • Um framework de mocks:
      • Deve refletir a forma como você pensa
  • Framework de Testes
  • Codebase
    • Comparação entre código e linhas de teste 1:1 (se possível)
    • Testes devem crescer junto com seu código
      • Classes auxiliares, métodos, custom matchers, etc
    • Conforme seu projeto vai crescendo, a dificuldade de escrever novos testes deve ficar constante ou diminuir!
  • Mocks
    • Expectations: antes do teste, o define-se o que esperamos que o mock receba
      • (Mocha, RSpec, FlexMock, JMock)
    • Assertions: depois do teste, vemos o que o mock recebeu
      • (Mockito)
  • Eu uso...
    • Para Ruby: RSpec, e às vezes, Mocha
    • Para Scala: ScalaTest com Mockito
    • Para Java: JUnit (com os Hamcrest matchers) e Mockito
    • Para JavaScript: Jasminne
  • Primeiro, resolva o problema
    • Represente! A vida é um teatro!
    • Não escreva NADA antes de resolver o problema
    • Protótipos são válidos, mas devem ser descartados
  • Então, escreva o código
    • Teste vem PRIMEIRO
    • Código vem DEPOIS
    • Somente um teste deve falhar por vez
      • Quer dizer...
  • Somente um teste falhando?
    • Mini-integrações
  • Ambiente Isolado
    • Todo teste, no BDD, é um cenário
    • Pensar num teatro:
      • Montar o cenário (Setup)
      • Apresentação (para o código)
      • Aceitação do público
      • Desmontar tudo
    • Peça foi um fracasso: ainda assim, desmontar tudo
      • TearDown
    Infra-Estrutura do Teatro Setup Apresentação Aceitação
  • Preparação não pode ficar implícita
    • (Muito comum no RSpec / Ruby)
  • Mas também, nada de explícita
    • (Comum com situações que exigem muito ”setup”)
  • Meio-Termo
    • Métodos que ajudam a construir o cenário ideal
  • Métricas (LOC)
    • Setup (montar o cenário):
      • Ideal: de 1 a 4 linhas
      • Ruim: de 5 a 7 linhas
      • Maior que 7: Rever a preparação do Cenário
    • Chamada de método:
      • Ideal: 1 linha
      • Péssimo: maior que 2 linhas
    • JAMAIS:
      • Use IF, CASE, ou qualquer condicional!
  • Estilo de Teste Como fazer seu teste ter menos cara de código e mais cara de texto.
  • Bee English
    • Dê sentido para as coisas!
  • Bee English
    • Falta de Sentido: ”que é que isso fazia mesmo???”
  • Bee English
    • Pense em como você descreveria aquele pedaço
    • Adapte o texto até chegar à linguagem de teste
  • Bee English
    • Monte sua ”história” baseando-se na linguagem
  • Uma Última Coisa Mocks e Stubs
  • Stub!
    • Stub como forma de ”controle”
    • Programação Funcional
    Stub em algum lugar aqui dentro...
  • Devil's Advocate
    • Mas... e com a correria?
      • Mas... você não demora mais pra fazer isso?
    • Mas... a empresa (coloque aqui sua empresa favorita) não usa isso...
    • Mas... meu código sequer tem testes, como eu vou aplicar isso?
  • That's It
    • Perguntas?
    • Idéias?
    • Contato:
      • [email_address]
      • @mauricio_szabo
      • http://mauricioszabo.wordpress.com
      • http://github.com/mauricioszabo/AgileBrazil2011