• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Mantendo a Qualidade dos Códigos de Teste
 

Mantendo a Qualidade dos Códigos de Teste

on

  • 1,233 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,233
Views on SlideShare
1,122
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

11 of 1 previous next

  • 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