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
5. @dudumendes
Contexto do Processo de
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 Processo de
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
10. @dudumendes
Ciclos no Processo 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
13. @dudumendes
Melhores práticas para
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 vida do
@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
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
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ásico do TDD
F
Fazer um código
Escrever um passar no teste
teste unitário
que falha
Refatorar
34. @dudumendes
Benefícios do TDD
•Escrevendo testes
•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
•Executando testes
•detecta erros enquanto o contexto
do código ainda está em mente
•avisa quando fizemos o bastante,
evitando esforço desnecessário
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
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?
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
53. TDD
Escreva o teste primeiro
•pense no design
•controle o escopo
Teste
crie o teste utilizando assertivas
•teste o que é esperado
e o que não é esperado
61. @dudumendes
TDD é
um método*
para construir software
*método:
abordagem repetítivel - ciclo
para solucionar um determinado
problema - aprendizado
Hinweis der Redaktion
\n
\n
\n
Contextualizar o processo / Conjunto de atividades que levam a um sistema\n
\n
\n
Anotar mudanças e incertezas\n
Anotar mudanças e incertezas\n
Discutir um pouco as práticas para levar o benefício do feedback\n
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
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
\n
\n
\n
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
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
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
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
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Código limpo\ntestes como especificação\naumento de confiança\n
Código limpo\ntestes como especificação\naumento de confiança\n
\n
\n
\n
\n
\n
\n
\n
\n
Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
Problema: quando integra o sistema, propriedades emergentes surgem e quebram\n
\n
\n
\n
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
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
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