Test Driven Development

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Fazer uma introdução sobre Testes automatizados Falar sobre os objetivos da apresentação Vamos falar de testes unitários

    Favorites, Groups & Events

    Test Driven Development - Presentation Transcript

    1. Test - Driven Development Luiz Augusto Moreira da Costa Sistemas Comerciais
    2. Por que não testar?
      • “ É difícil demais” / “Eu não sei como fazer isso meu fi!!”
      • “ Você tá doido, preciso terminar isso logo!”
      • “ Meu código funciona!”
      • “ Desse jeito vou programar dobrado!”
      • “ Não é problema meu...”
    3. E se eu não testar?
      • Refatorar? Migrar? Mé que vai fazê ?
      • Problemas de manutenção
      • Debug
    4. TDD, o que é isso ?
      • TDD é sobre escrever testes antes de escrever código
      • Seus testes irão guiar o desenvolvimento
      • Um teste
        • É parte do seu código
        • É automatizado
        • É executado repetidamente a cada mudança
    5. TDD, o que é isso ?
      • É uma especificação
        • O teste fornece uma especificação do que uma parte do código faz atualmente
        • Teste é parte da documentação
      • É muito utilizado em métodos ágeis como eXtreme Programming(XP)
    6. Por que TDD ?
      • Melhoria da qualidade
        • TDD não ajuda a entregar código sem bugs, mas a qualidade irá melhorar
      • TDD faz os testes acontecerem
      • Simplicidade do Design
        • Complexidade produz bugs
      • Aumento da produtividade
        • Mé que é ????
    7. Por que TDD ?
      • Testes irão validar requisitos muito cedo
        • Erros de entendimento serão eliminados rapidamente
        • Requisitos “esquisitos“ serão eliminados rapidamente
      • Mudanças sem medo
        • Impactos das mudanças verificado rapidamente
      • Feedback o tempo todo
    8. Passos para aplicação de TDD
        • Inicie escrevendo um teste
          • Escreva o teste antes da implementação
          • Faça o teste falhar
        • Escreva código suficiente para o teste passar
          • Escreva testes pequenos: teste a menor quantidade possível de código de cada vez.
        • Refatorar
        • Executar novamente para garantir que os testes continuam passando
    9. Passos para aplicação de TDD
        • Inicie escrevendo um teste
          • Escreva o teste antes da implementação
          • Faça o teste falhar
        • Escreva código suficiente para o teste passar
          • Escreva testes pequenos: teste a menor quantidade possível de código de cada vez.
        • Refatorar
        • Executar novamente para garantir que os testes continuam passando
      Este é o TDD Mantra ( Red Green Refactor )
      • Demonstração
      • Modelo de domínio – Produtos
      • Primeiro, vamos a uma rápida sessão de Design...
    10. Sessão de Design Alguns requisitos do modelo
        • Modelo proposto:
      Produto Sku
        • O produto deve conhecer seus skus.
        • Qual quantidade de skus de um produto ?
        • Existe algum sku Classe “D” em um produto ?
      *
    11. Então ...
        • É preciso prática
        • É preciso disciplina
        • É preciso conhecer um pouco de OO
    12. Mas ... como sempre, problemas
        • É difícil testar Interface com Usuário
        • É difícil trabalhar com dados persistentes
        • O falso senso de segurança
        • Perdemos uma visão geral
        • Temos mais código para manter
    13. Pra onde estamos indo...
        • Test-Driven Development
        • Behavior Driven Development (BDD)
    14. Exemplo de BDD (em Ruby ????)
        • Steps_for (:conta) do
        • Given (“ minha conta $ tipo_conta tem saldo $saldo ”) do |tipo_conta,valor|
        • criar_conta(tipo_conta, valor)
        • end
        • When (“ eu transferir $valor de $conta_origem para $conta_destino ”) do |valor, conta_origem, conta_destino| obter_conta(conta_origem).transferir(valor) .para(conta_destino)
        • end
        • Then (“ minha conta $tipo_conta deve ter saldo $valor ”) do |tipo_conta,valor| obter_conta(tipo_conta).O_saldo_deve_ser(valor)
        • end
        • end
    15. Aquele código estranho se transforma...
    16. Conclusão
        • Escrevam testes!
    17. Referências
        • TDD - http://www.agiledata.org/essays/tdd.html
        • TDD - http://www.improveit.com.br/xp/praticas/tdd
        • BDD - : http://behaviour-driven.org/
        • Rspec - http://rspec.info
        • Livros
        • Applying Domain-Driven Design and Patterns – Jimmy Nilsson
        • Test-Driven Development by Example – Kent Beck
      • Obrigado!

    + Luiz  CostaLuiz Costa, 8 months ago

    custom

    956 views, 0 favs, 0 embeds more stats

    Apresentação feita a equipe de desenvolvimento qu more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 956
      • 956 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 19
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories