• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
TDD e Refactoring
 

TDD e Refactoring

on

  • 748 views

 

Statistics

Views

Total Views
748
Views on SlideShare
748
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

    TDD e Refactoring TDD e Refactoring Presentation Transcript

    • TDD e RefactoringAndré Luís PitombeiraSaturday, May 25, 13
    • Quem sou eu?• Bacharel em Sistemas de Informação (UFC/Quixadá)• Bacharel em Administração de Empresas (FCRS)• Desenvolvedor de Software do lsbdSaturday, May 25, 13
    • Quem são vocês?• Respondam estas três perguntas• Qual o seu nome?• O que você faz da vida?• O que você espera deste curso?Saturday, May 25, 13
    • Objetivos• Definir os principais conceitos relacionados aoTDD e Refactoring• Mostrar boas práticas de programação e design desistemas• Demonstrar o uso de algumas ferramentasSaturday, May 25, 13
    • Programação• Primeira parte• Test-Driven Development (TDD)• Segunda parte• RefactoringSaturday, May 25, 13
    • Test-Driven Development (Parte I)Saturday, May 25, 13
    • Agenda• Motivação• Famílias e tipos de testes• Teste unitário• Test-Driven Development• Exercício de fixaçãoSaturday, May 25, 13
    • O problemaBarato RápidoBomSaturday, May 25, 13
    • No silver bullet!Saturday, May 25, 13
    • Porém, com testes...• Um pouco mais rápido• Um pouco mais barato• Um pouco melhorSaturday, May 25, 13
    • Rápido02505007501000Projeto Implementação QA Post-releaseTempo gasto para resolver bugsSaturday, May 25, 13
    • Barato• Bugs são descobertos nas fases iniciais dodesenvolvimento• Custo para resolver bug = Número de bugs /Custo por bug resolvido• Custo dos testes = Número de features /Complexidade das featuresSaturday, May 25, 13
    • Melhor• Desenvolvimento tradicional• Instintivo• Difícil de mensurar• TDD• Indicativo• Mensurável• TestávelSaturday, May 25, 13
    • Então, a solução é testarSaturday, May 25, 13
    • Mas por que os desenvolvedoresdeveriam escrever testes?• Respostas comuns• Deixa os testes para o QA• Desenvolvedores são muito ocupados• Desenvolvedores não sabem como testar• Nós não temos bugs• Desenvolvedores não são adequados para testaro códigoSaturday, May 25, 13
    • Os desenvolvedores deveriamconsiderar isto...• Como os desenvolvedores vão saber que estãofazendo software de qualidade sem os testes?• Testes são uma ferramenta para ajudar osdesenvolvedores a contribuírem para qualidade• Testes ajudam a dar perquenos passos e receberfeedback constante• Testes ajudam a manter o foco sobremensuráveis resultados de desenvolvimentoSaturday, May 25, 13
    • Panorama da indústria• Principais problemas relatados na adoção detestes pela indústria• Aumenta o tempo de desenvolvimento• Experiência ou habilidade insuficiente• Insuficiente design• Insuficiente aderência ao TDD• Falta de ferramentasSaturday, May 25, 13
    • O que é um teste de software?Saturday, May 25, 13
    • “O teste de software é ainvestigação do software a fimde fornecer informações sobresua qualidade em relação aocontexto em que ele deveoperar. Isto inclui o processo deutilizar o produto paraencontrar seus defeitos.”WikipediaSaturday, May 25, 13
    • O que é qualidade de software?Saturday, May 25, 13
    • “A qualidade de software é umaárea de conhecimento daengenharia de software queobjetiva garantir a qualidade dosoftware através da definição enormatização de processos dedesenvolvimento.” WikipediaSaturday, May 25, 13
    • Tipos de teste (Alguns)• Teste funcional• Teste de usabilidade• Teste de stress• Teste de aceitação• Teste de regressão• Teste de configuração• Teste unitárioSaturday, May 25, 13
    • Famílias de Teste• XUnit (JUnit, PyUnit, JsUnit)• “assert”• TAP (libtap)• “ok” ou “is”Saturday, May 25, 13
    • Teste unitário“Teste unitário é o método pelo qual unidades decódigo são testadas para verificar se estas estão aptaspara o uso. Uma unidade é a menor parte testável deuma aplicação.” WikepediaSaturday, May 25, 13
    • Por que teste unitário?• Debugar é um processo que consume tempo• Quando novas funcionalidades são adicionadas,como assegurar que as antigas não quebraram?• Ver a classe em ação• Medida de qualidade de softwareSaturday, May 25, 13
    • Teste unitário é bom se...• É realmente automático• Testa tudo que é provável quebrar• Deve ser independente de ambiente e de outrostestes• Deve ser repetitivo e mostrar sempre o mesmoresultado toda vez que executar• O teste deve ser claroSaturday, May 25, 13
    • Exemplo de teste unitáriopublic void marriageIsSimmetric(){Customer alice = new Customer();Customer bob = new Customer();bob.marry(alice);assertTrue(bob.ismariedTo(alice));assertTrue(alice.ismariedTo(bob));}Saturday, May 25, 13
    • hands-on!Saturday, May 25, 13
    • O que é TDD?• Uma técnica iterativa para desenvolver software• Escreva primeiro um teste que falha(ou até mesmonão compile), antes de escrever uma novafuncionalidade• O objetivo do TDD é especificação e não validação• Uma prática para evoluir o código eficientementeSaturday, May 25, 13
    • Ciclo do desenvolvimento com TDDSaturday, May 25, 13
    • Regras fundamentais do TDD• Escreva somente o código suficiente para o testepassar• Escreva testes pequenos• Escreva testes muito rápidosSaturday, May 25, 13
    • Motivações para o uso do TDD• Design pouco testável• Baixa cobertura de testes unitários• Necessidade de levantar todo o ambiente parapoder testar• Necessidade de manter compatibilidade retroativa• Insegurança ao modificar a base de códigoSaturday, May 25, 13
    • Benefícios em usar TDD• Suíte de regressão• Testes são feitos na IDE• Bugs comprovados por testes unitários• Código mais testável• Facilita o refactoring• Evita o “overdesign”• Colabora com a documentaçãoSaturday, May 25, 13
    • Ponderações sobre o uso do TDD• Demora mais?• No início é necessário escrever muitos testes• Suite de regressão• Certeza de que a implementação está rodando• Maioria dos bugs encontrados em tempo dedesenvolvimento• Bugs corrigidos mais rápidosSaturday, May 25, 13
    • TDD é código que funciona• Previsível• Aprendizagem• Confiança• Documentação• Proteção• Teste suite automatizadoSaturday, May 25, 13
    • Quando devo parar?• O sistema funciona• O código comunica o que está fazendo• Não existe código duplicado• O sistema deveria ter a menor quantidade possívelde classes e métodosSaturday, May 25, 13
    • TDD é sobre design, não sobre testes• Use TDD para produzir algo simples que funcione(KISS)• Guie o design do software através dos testes• Foque sobre escrever soluções simples para osrequisitos• Escreva somente código para o teste passar• Remova código duplicado (DRY)Saturday, May 25, 13
    • TDD vs UML• Análise prévia do problema• Reutilização de código• Linguagem unificada para especificação desistemas• Aumento na qualidade• Ferramenta de aprendizado• Facilidade de manutençãoSaturday, May 25, 13
    • hands-on!Saturday, May 25, 13
    • Tópico para discussão• Deveríamos testar métodos privados?• Sempre devemos usar TDD?Saturday, May 25, 13
    • Perguntas?Saturday, May 25, 13
    • Obrigado!Saturday, May 25, 13
    • Test-Driven Development (Parte II)Saturday, May 25, 13
    • Agenda• Revisão• JUnit• Mock• Padrões de TDD• ExercíciosSaturday, May 25, 13
    • Cenas dos capítulos anteriores...Saturday, May 25, 13
    • Cenas dos capítulos anteriores...Saturday, May 25, 13
    • JUnitSaturday, May 25, 13
    • JUnit• Annotations• @Test• @Before e @After• @BeforeClass e @AfterClass• @Test(expected = ArithmeticException.class)• @Ignore• @Test(timeout = 1000)Saturday, May 25, 13
    • JUnitAssertions do JUnitSaturday, May 25, 13
    • MockSaturday, May 25, 13
    • Exemplo de mock (Simples)Saturday, May 25, 13
    • Exemplo de mock (Um pouco maiscomplexo)Saturday, May 25, 13
    • Padrões de TDD• O que queremos testar?• Quando testamos?• Como escolhemos que lógica testar?• Como escolhemos quais dados testar?Saturday, May 25, 13
    • Padrões de TDD• Teste (substantivo)• Teste isolado• Lista de testes• Teste primeiro• Defina uma asserção primeiro• Dados de teste• Dados evidentesSaturday, May 25, 13
    • Exercícios de TDD• Valida RG• Valida Chassi• Valida CPFSaturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13
    • Test-Driven Development (Parte III)Saturday, May 25, 13
    • Agenda• ExercícioSaturday, May 25, 13
    • Dinheiro Multi-MoedaInstrumento Ações Preço TotalApple 1000 25 USD 25000 USDGoogle 400 150 CHF 60000 CHFTotalTotalTotal 65000 USDDe Para TaxaCHF USD 1,5Saturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13
    • Refactoring (Parte I)Saturday, May 25, 13
    • Agenda• Conceitos básicos• ExemploSaturday, May 25, 13
    • O que é refactoring?Saturday, May 25, 13
    • Saturday, May 25, 13
    • hands-on!Saturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13
    • Refactoring (Parte II)Saturday, May 25, 13
    • Agenda• Conceitos básicos• Motivos para refatorar• Princípios de design de software• “Mau cheiro”• Ciclo do refactoring• Técnicas de refactoring• ExercícioSaturday, May 25, 13
    • • Refactoring(substantivo) - Mudança feita naestrutura interna do software para fazê-lo fácil deler e barato de mudar sem alterar seucomportamento• Refactor(verbo) - Reestruturar o software atravésde uma série de refactorings sem alterar seucompotamentoSaturday, May 25, 13
    • O propósito do refactoring é fazer osoftware fácil de entender e modificarSaturday, May 25, 13
    • Por que você deveria refatorar?Saturday, May 25, 13
    • Alguns porquês...• Melhorar o design do software• Fazer o software mais fácil de entender• Encontrar bugs• Escrever código mais rapidamenteSaturday, May 25, 13
    • Princípios de design de software• Princípio da responsabilidade única• Princípio aberto fechado• Princípio da substituição de Liskov• Princípio da injeção de dependência• Princípio de segregação de interfaceSaturday, May 25, 13
    • “Mau cheiro” no código(Não é isso)Saturday, May 25, 13
    • “Mau cheiro” no códigoSaturday, May 25, 13
    • O ciclo do refactoring• O escolha o “mau cheiro”• Selecione uma refatoração• Aplique a refatoração• Execute todos os testesSaturday, May 25, 13
    • Técnicas de RefactoringSaturday, May 25, 13
    • hands-on!Saturday, May 25, 13
    • Saturday, May 25, 13
    • Saturday, May 25, 13