TDD

TDD@joaovictorino

Agilidade e XP TDD TDD em .Net TDD na prática Referências

Conteúdo

Indivíduos e interação mais que processos e ferramentas

Software funcionando mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Manifesto ágil

Kent Beck (XP, TDD) Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler (Patterns, Refactoring) James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert Martin (Clean Code, Agile) Steve Mellor Ken Schwaber (Scrum) Jeff Sutherland Dave Thomas

Pessoas que estavam no dia

Custo

Tempo

Qualidade

Escopo*

Variáveis de um projeto

Simples, leve, rápido e divertido

São as práticas que mais agradam os programadores e que causaram maior “barulho” nas empresas e na comunidade

O primeiro livro de XP é o livro do Kent Beck

XP (eXtreme Programming)

XP (eXtreme Programming)

Comunicação Simplicidade Feedback Respeito Coragem

Valores e regras do XP

Espaço aberto (todos juntos com o cliente, sem baias, war rooms, flipcharts, lousas e etc)

Programação em pares (nivelamento de conhecimento técnico e do projeto)

Movimente as pessoas Cliente sempre próximo Código coletivo Metáfora do sistema TDD Padrões de código

Comunicação

TDD (desenvolvimento guiado a testes) Modelagem simples (KISS - Keep it simple,

stupid!) Ser simplista não é não pensar no futuro

mas não faça aquilo que não é necessário Refatorar sempre, sem misericórdia Pequenos releases Metáfora do sistema Padrões de código

Simplicidade

Integração continua (controle de versão, servidor de build, testes, inspeção de código e feedback)

Cliente sempre próximo Pequenos releases Programação em pares Código coletivo

Feedback

Jogos de planejamento (planning poker) Semanas de 40 horas Ritmo sustentável Pequenos releases

Respeito

Jogos de planejamento (planning poker) Código coletivo Programação em pares Refatorar sempre, sem misericórdia Integração contínua TDD

Coragem

Desenvolvimento guiado por testes O primeiro livro sobre o assunto também foi

escrito pelo Kent Beck A prática mais viciante e uma das mais

importantes do XP Fácil de explicar mas difícil de aprender

(dói) e leva tempo, mas de retorno garantido

TDD (Test driven development)

Código mais claro Testes são documentações executáveis Testes garantem funcionalidades do domínio

do problema Se algum teste parou de rodar, sabemos que

algo deu errado Independência de uma camada gráfica para

testar as camadas mais baixas(negócios, db, etc)

Economia de tempo e dinheiro em manutenção

Porque usar TDD?

Você deve criar uma grande quantidade de testes

Nenhum código vai para produção sem ter um teste correspondente

O teste SEMPRE é escrito antes Rode seus testes com frequencia O teste te diz que código de produção você

deve escrever Primeiro eu codifico o teste, depois codifico

o código de produção


Não escreva código de produção até que você tenha escrito um teste unitário falho

Não escreva mais do que um teste que já seja suficiente para falhar, não compilar é uma falha

Não escreva no código de produção mais do que o suficiente para passar no seu teste falho

Regras do TDD

Testar é fácil, se está difícil escrever um teste o código está mal feito

TDD nos leva a usar boas práticas de modelagem e arquitetura

TDD nos leva a um baixo acoplamento TDD nos leva a desenvolver para interfaces Refatore sem medo, afinal você está

coberto pelos testes

Não esqueça!

Sempre que encontrar um bug escreva um teste que o exponha

Os testes devem evoluir, assim como o código evolui

Testes que não são atualizados são apenas código legado

Aprender a escrever testes é também um processo gradativo

Crie testes as Exceptions

Não esqueça! 2


Reescrever o código de forma que fique mais fácil o seu entendimento e por consequência a sua manutenção

Ninguém faz nada perfeito da primeira vez Na verdade não existe código perfeito, ele

sempre tem alguma coisa que pode melhorar

Será que eu não introduzi bugs quando refatorei?

Refatorar

Tanto o código de teste quanto o código de produção devem ser constantemente refatorados

Durante o processo do TDD o código de produção é revisto várias vezes

Criar testes me garante que posso refatorar a vontade, pois os testes vão me avisar caso eu insira algum bug

Refatorar em TDD

Classes com nomes que sejam substantivos Métodos com nomes que sejam verbos Propriedades com nomes que sejam

substantivos Variáveis com nomes que sejam

substantivos Nomes que tenham significado de negócio Convenções de nomes Evite comentários no código, se você

precisa comentar é porque seu código não está claro então reescreva

Qualidade do código no TDD

S.O.L.I.D.

Apenas um Assert por teste Um conceito por teste F.I.R.S.T.

◦ Fast – rápidos de rodar◦ Independent – independentes entre si◦ Repeatable – fáceis de executar a qualquer

momento◦ Self-Validating – fácil de descobrir se deu certo ou

não◦ Timely – teste deve ser feito pouco antes do

código de produção

Regras de um teste

São objetos fake que permitem que o teste seja isolado em apenas uma classe

Serve para remover dependências que o teste pode ter como, banco de dados, web services, outras classes, entre outros

Mocks e Stubs

Une classes e componentes em tempo de execução

Permite que quando estivermos rodando os testes apontemos para classes stubs e quando o código for executado em produção volte para as classes originais

Não é indispensável, mas é útil

Conteiner de injeção de dependência

TDD em .Net

TDD veio do Java mas ...

Apoio pela IDE Apoio dos frameworks Inúmeros frameworks open-source também

WCF

ASPNET MVC

WPF MVVM

Web Forms MVP

Suporte a TDD do VS 2012 Criação de testes unitários Criação de stubs Criação de classes e métodos automatizadamente Ambiente para execução dos testes unitários (Test

Explorer) Ferramenta de análise de cobertura de código

(Code Coverage) Ferramenta de análise da complexidade do código

(Code Metrics) Ferramenta para teste de desempenho e carga

(Performance Wizard)

Referência

Robert C. Martin (Uncle Bob)

2002

Referência

Kent Beck 2002

Referência


2008

Referência


2011

Referência

Kent Beck 2004

Referência

Eric Evans 2003

Referência

Jimmy Nilsson 2006

Referência

Martin Fowler 2009

Referência

Michael Feathers 2004

Referência

James Bender Jeff McWherter 2011

Dúvidas?

Documents

TDD