Transferir como PDF, PPTX
Carregado porEduardo Mendes
Introdução ao TDD
O documento discute o desenvolvimento baseado em testes (TDD) em 3 frases: 1) TDD envolve escrever testes unitários antes de escrever o código para guiar o desenvolvimento e garantir a qualidade do código. 2) O ciclo básico do TDD é escrever um teste que falha, escrever o código mínimo para fazer o teste passar, e refatorar o código. 3) Os benefícios do TDD incluem esclarecer os requisitos, desenvolver código de alta qualidade com
Mais conteúdo relacionado
Introdução ao TDD
- 1. @dudumendes Desenvolvimento Baseado em Testes Eduardo Mendes de Oliveira edumendes@gmail.com
- 2. @dudumendes Agenda • Introdução • Conceitos de desenvolvimento orientados a testes • TDD / BDD • Revisão de Refatoração • Padrões de teste • Ferramentas • Aulas práticas 2
- 3.
- 4. @dudumendes Processo de Software Projeto e Especificação Implementação Validação Evolução
- 5. @dudumendes Contexto do Processode Sofware - Equipe •Algo novo para a equipe de software •pessoas envolvidas •domínio da aplicação •tecnologia utilizada •uma combinação dos 03 anteriores •Elementos surpresas
- 6. @dudumendes Contexto do Processode Sofware - Cliente •Obriga a criar um novo olhar sobre a organização a partir de uma nova perspectiva •É preciso negociar e formalizar processos que até então eram baseados na experiência e convenções
- 7. @dudumendes Processo de Software Processo de aprendizagem •Sucesso do projeto •Entender o progresso do projeto •trabalho conjunto para identificar e resolver mal-entendidos •É preciso um processo que ajude a lidar com as incertezas e antecipar mudanças inantecipadas
- 8. @dudumendes Princípios ágeis fundamentais •Desenvolvimento incremental •Envolvimento do cliente •Pessoas, não processos •Aceitar as mudanças •Envolvimento do cliente
- 9. Incremento + @dudumendes Feedback analisar projetar implantar implementar CICLO feedback
- 10. @dudumendes Ciclos noProcesso de Software •Testes de unidade •Testes de aceitação •Reuniões diárias •Releases
- 11. Lidando com a @dudumendes mudança • Possuir testes de regressão sempre • adicionar funcionalidades sem quebrar as existentes • escrever testes às vezes é visto como uma tarefa chata • Manter a simplicidade (FOWLER, 1999) • Código fácil de manter e modificar • exige esforço de refatoração constante
- 12.
- 13. @dudumendes Melhores práticaspara programação •Evitar código spaghetti •Incluir comentários relevantes nos fontes •Criar testes antes ou concomitantemente à codificação •Inspeções formais •Re-inspeções de código após mudanças significativas •Renovar código legado antes de melhorias
- 14. @dudumendes TDD •Teste antes, teste primeiro •ao invés de deixar o teste verificar o trabalho depois de feito •Teste como atividade de projeto •esclarece as ideias sobre o que queremos que o código faça •separação dos projetos físicos e lógicos
- 15. Ciclo de vidado @dudumendes software Densenvolvimento em um primeiro momento só existiam 02 fases Manutenção 15
- 16. @dudumendes Ciclos ruins •Quando se chega na época de entregar o software •Cliente não está satisfeito •Por falta de tempo, o software é entregue sem testes
- 17. @dudumendes Espiral da morte menostestes mais problemas menos tempo
- 18. Abordagens Ágeis Test First ✦ Modifica a abordagem tradicional para modelar e analisar •Kent Beck ✦ Cria práticas para fornecer apoio ao Test First Baby Steps 18
- 19.
- 20.
- 21.
- 22. TDD • “Test-driven development is a way of managing fear during programming.” Kent Beck
- 23. TDD • “Desenvolvimento baseadoem testes é uma forma de administrar o medo durante a programação.” Kent Beck
- 24. “Alguém sabe o que isso faz?”
- 25. “Eu acho quenão temos nenhuma documentação para isso!”
- 26. “Se eu mudarX provalvemente Y vai quebrar!”
- 27. “Na última vezque peguei nesse negócio, nós passamos uma semana para corrigí-lo.”
- 28.
- 29.
- 30. TDD @dudumendes Escreva um teste ANTES de escrever um código a ser testado Escreva um código que apenas faça compilar o teste e observe o teste funcionando Refatore para o formato mais simples possível
- 31. @dudumendes O ciclo básicodo TDD F Fazer um código Escrever um passar no teste teste unitário que falha Refatorar
- 32. @dudumendes red / green/ refactor
- 33. @dudumendes Feedback doTDD •Implementação •Funciona? •Projeto •Está bem elaborado?
- 34. @dudumendes Benefícios do TDD •Escrevendotestes •esclarece os critérios de aceitação •encoraja a escrever componentes fracamente acoplados para que sejam testados isoladamente •atribui uma descrição executável do que o código faz •ganha-se uma suíte de regressão completa
- 35. @dudumendes Benefícios do TDD •Executandotestes •detecta erros enquanto o contexto do código ainda está em mente •avisa quando fizemos o bastante, evitando esforço desnecessário
- 36. @dudumendes Benefícios resumo •O projetoevolui constatemente •O projeto está sobre constante revisão •qualidade de código •fraco acoplamento •alta coesão
- 37. @dudumendes Regra de Ourodo TDD “Nunca codifique uma funcionalidade nova sem um teste falhando”
- 38.
- 39. Testes preparar Unitários Componente “resetar” testado de executar maneira isolada validar
- 40. TDD @dudumendes x Testes unitários •TDD é somente a utilização de testes unitários? •melhor do que nada! •às vezes os testes ficam isolados e não podem ser integrados
- 41. @dudumendes Poronde começar? • Por onde começa um projeto?
- 42. @dudumendes Regra de Ourodo TDD “Nunca codifique uma funcionalidade nova sem um teste falhando”
- 43. @dudumendes Por onde começar? Fazer um código F Escrever um passar no teste teste unitário que falha Escrever um Refatorar teste de aceitação que falha
- 44. @dudumendes Níveis de teste • Aceitação • O sistema funciona como um todo? • Integração • Nosso código funciona com o código já existente? • Unidade • Nossos objetos fazem a coisa certa do jeito certo?
- 45. Processo de Software Requisitos Projeto Implementa Teste Evolução
- 46. Processo de Software com TDD Projeto Implementa Teste
- 47. Processo de Software com TDD Projeto Teste Implementa
- 48. Processo de Software com TDD Projeto Teste Implementa Teste
- 49. TDD Projeto Teste Teste Implementa
- 50. TDD Projeto Teste Teste Implementa
- 51. TDD Projeto crie uma lista de teste anote e identifique os testes seja conciso: uma classe ou método posteriormente, é possível adicionar mais testes
- 52. TDD Projeto Teste
- 53. TDD Escreva o testeprimeiro •pense no design •controle o escopo Teste crie o teste utilizando assertivas •teste o que é esperado e o que não é esperado
- 54. TDD Teste Implementa
- 55. TDD implemente o códigoque deve ser testado faça o mínimo e somente o necessário para que o teste compile e passe Implementa
- 56. TDD Teste Implementa
- 57. TDD Teste Verifique se o teste passou
- 58. TDD Projeto Teste E tudo de novo! Teste Implementa
- 59. @dudumendes Entendi! Já sei! TDD é um método para testar software
- 60.
- 61. @dudumendes TDD é um método* para construir software *método: abordagem repetítivel - ciclo para solucionar um determinado problema - aprendizado
Notas do Editor
- #2 \n
- #3 \n
- #4 \n
- #5 Contextualizar o processo / Conjunto de atividades que levam a um sistema\n
- #6 \n
- #7 \n
- #8 Anotar mudanças e incertezas\n
- #9 Anotar mudanças e incertezas\n
- #10 Discutir um pouco as práticas para levar o benefício do feedback\n
- #11 Implantar é a oportunidade de checar as suposições frente à realidade / Sem implantar não como ter um feedback completo\n A cada ciclo de incremento se repetem as etapas de desenvolver e obter feedback / Maneira de aprender algo sobre o sistema e aplicar este conhecimento de volta ao sistema\n
- #12 Cada ciclo oferece um feedback em que o time pode descobrir e corrigir erros\nOs ciclos internos focam no detalhe, o ciclos exteros focam na organização e no time\nQuanto mais cedos obtivermos o feedback, melhor\n
- #13 \n
- #14 \n
- #15 \n
- #16 O esforço para escrever o teste primeiro dá-nos FEEDBACK sobre a qualidade das nossas ideias\nFazer código testável torna o desenvolvimento mais limpo e mais modular\nSe se escreve testes durante o processo de desenvolvimento, então TESTES de REGRESSÃO\n
- #17 \n
- #18 \n
- #19 \n
- #20 \n
- #21 \n
- #22 \n
- #23 \n
- #24 \n
- #25 \n
- #26 \n
- #27 \n
- #28 \n
- #29 Onde meu software está quebrando? Vou ter que fazer manutenção demais!\n\nO medo nos faz hesitantes\nO medo nos faz diminuir a comunicação\nO medo nos afastam do feedback\nO medo nos faz mal-humorados\n
- #30 Onde meu software está quebrando? Vou ter que fazer manutenção demais!\n\nO medo nos faz hesitantes\nO medo nos faz diminuir a comunicação\nO medo nos afastam do feedback\nO medo nos faz mal-humorados\n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 \n
- #36 \n
- #37 \n
- #38 \n
- #39 \n
- #40 \n
- #41 \n
- #42 \n
- #43 \n
- #44 \n
- #45 \n
- #46 \n
- #47 Código limpo\ntestes como especificação\naumento de confiança\n
- #48 Código limpo\ntestes como especificação\naumento de confiança\n
- #49 \n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
- #58 Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
- #59 Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
- #60 \n
- #61 \n
- #62 \n
- #63 Os testes de aceitação demoram mais a passar / Testes de unidades devem passar logo depois que foram escritos / Testes unitários não devem comprometer o repositório de origem / Testes de aceitação devem estar presentes por todo o sistema / testando a GUI\n\n
- #64 Os testes de aceitação demoram mais a passar / Testes de unidades devem passar logo depois que foram escritos / Testes unitários não devem comprometer o repositório de origem / Testes de aceitação devem estar presentes por todo o sistema / testando a GUI\n\n
- #65 Os testes de aceitação demoram mais a passar / Testes de unidades devem passar logo depois que foram escritos / Testes unitários não devem comprometer o repositório de origem / Testes de aceitação devem estar presentes por todo o sistema / testando a GUI\n\n
- #66 \n
- #67 \n
- #68 \n
- #69 \n
- #70 \n
- #71 \n
- #72 \n
- #73 \n
- #74 \n
- #75 \n
- #76 \n
- #77 \n
- #78 \n
- #79 \n
- #80 \n
- #81 \n
- #82 \n
- #83 \n
- #84 \n
- #85 \n
- #86 \n
- #87 \n
- #88 \n
- #89 \n