Vous êtes sur la page 1sur 23

Como convencer

seu chefe sobre TDD?

Maurcio Aniche

COMO
CONVENCER
SEU CHEFE
SOBRE TDD?
Maurcio Aniche

http://tdd.caelum.com.br

SUMRIO
Test-Driven Development ...................................... 3
Como funciona?.................................................. 4
Vantagens ........................................................ 6
O que eu ganho com a prtica? ............................ 6
Devo praticar TDD 100% do tempo? ....................... 7
Qual a diferena entre fazer TDD e escrever o teste
depois? ......................................................... 8
Benefcios ....................................................... 10
Serei mais ou menos produtivo? .......................... 10
Estudos cientficos ............................................. 13
Algum j fez estudos formais sobre isso? .............. 13
Referncias ..................................................... 15
Onde posso ler mais sobre isso? ........................... 15
Treinamentos ................................................... 19
Como treinar minha equipe? .............................. 19
Verso............................................................ 20
Verses do documento ..................................... 20
Sobre o Autor ................................................... 21
Organizadores .................................................. 22

TEST-DRIVEN DEVELOPMENT
Test-Driven Development (TDD), sem dvida, tornou-se
uma das prticas mais populares entre desenvolvedores
de software. A ideia bem simples: escreva seus testes
antes mesmo de escrever o cdigo de produo. Mas por
qu a ideia parece to boa? Ao escrever os testes antes, o
desenvolvedor garante que boa parte (ou talvez todo) do
seu sistema tem um teste que garante o seu
funcionamento. Alm disso, muitos desenvolvedores
tambm afirmam que os testes os guiam no projeto de
classes do sistema.
Mesmo com toda a indstria gritando as vantagens para
quem queira ouvir, ainda existem mitos em torno da
prtica. O desenvolvedor agora vai gastar mais tempo
escrevendo testes do que programando? Escrever testes
d trabalho. Testes manuais no so mais produtivos? TDD
deve ser feito 100% do tempo?
Este guia visa responder essas e outras perguntas para
voc, que desenvolvedor, gerente, ou est de alguma
forma relacionado ao processo de desenvolvimento de
software.

COMO FUNCIONA?
A mecnica da prtica simples: escreva um teste que
falha, faa-o passar da maneira mais simples possvel e,
por fim, refatore o cdigo. Esse ciclo conhecido como
Ciclo Vermelho-Verde-Refatora.

Sempre que um desenvolvedor pega uma funcionalidade


para fazer, ele a quebra (muitas vezes mentalmente) em
pequenas tarefas. Tarefas essas que exigem a escrita de
cdigo. Classes so criadas, outras so modificadas. Todas
essas modificaes tem um propsito, claro. Todo cdigo
escrito tem um objetivo.

Ao praticar TDD, o desenvolvedor antes de comear a


fazer essas modificaes explicita esses objetivos. S que
ele faz isso por meio de testes automatizados. O teste em
cdigo nada mais do que um trecho de cdigo que deixa
claro o que determinado trecho de cdigo deve fazer.
Ao formalizar esse objetivo na forma de um teste
automatizado, esse teste falha, claro; afinal, a
funcionalidade ainda no foi implementada. O
desenvolvedor ento trabalha para fazer esse teste
passar. Como? Implementando a funcionalidade.
Assim que o teste passar, o desenvolvedor ento parte
para uma prxima etapa no ciclo, importantssima para
aqueles que tem o sonho de produzir cdigo de
qualidade: a hora da refatorao. Refatorar melhorar o
cdigo que j est escrito. A cabea do desenvolvedor
complicada: quando ele est focado em implementar a
funcionalidade, ele raramente est pensando tambm em
qualidade de cdigo. No tem jeito, assim que
funcionamos. E justamente por isso que, aps a
implementao da funcionalidade, o desenvolvedor para
e melhora a qualidade do cdigo (que j funciona e
atende ao requisito do negcio).
Acabou? Claro que no. Agora partir para a prxima
funcionalidade. E comeando por onde? Pelo teste.

VANTAGENS
O que eu ganho com a prtica?
A prtica de TDD agrega muitos benefcios ao processo de
desenvolvimento. O primeiro deles, e mais claro, so os
benefcios na qualidade externa do produto. Todos j
sofremos os problemas de uma nova verso do produto
que traz novas funcionalidades, mas faz as anteriores
pararem de funcionar. A bateria de testes automatizados
gerados pela prtica do mais segurana ao
desenvolvedor na hora de mudanas.
Os testes automatizados, que rodam em questo de
segundos, so executados o tempo todo pelo
desenvolvedor. Isso quer dizer que podemos execut-los o
dia todo, muitas vezes por dia. Algo que sabemos ser
impossvel com testes manuais. Caso algo pare de
funcionar, o desenvolvedor rapidamente notificado, e
consegue corrigir o problema antes de mandar a verso
para o cliente. E todos ns sabemos o quanto bom no
estressar o usurio final com bugs, no verdade?
Alm disso, muitos autores populares da rea afirmam
que, caso o desenvolvedor saiba ler o cdigo de testes
com ateno, esse mesmo cdigo pode dar informaes
importantes sobre a qualidade do cdigo que est sendo
produzido. Dizemos que a prtica de TDD ajuda o
desenvolvedor a escrever cdigo de produo de
qualidade. difcil explicar esses efeitos em poucas

palavras, mas a ideia geral que se est difcil escrever


um teste automatizado, porque provavelmente o
cdigo de produo est complicado. Essa uma tima
dica para o desenvolvedor.
Perceba ento que o uso da prtica de TDD ajuda a
equipe a garantir que os requisitos funcionam como
esperado, e tambm auxilia o desenvolvedor a perceber
problemas de cdigo em suas implementaes. Dois
coelhos em uma cajadada s.

Devo praticar TDD 100% do


tempo?
A resposta para essa pergunta serve para toda e qualquer
prtica de engenharia de software. claro que no.
Como j discutido anteriormente, TDD faz com que o
desenvolvedor teste melhor sua aplicao, bem como
pense em um design de classes melhor e mais flexvel
para aquele problema. Mas no sempre que precisamos
disso. Se estamos, por exemplo, escrevendo a
implementao de um DAO (classe que se comunica com
o banco de dados), talvez escrever os testes antes no v
ajudar tanto, afinal no h grandes decises de design a
serem tomadas em classes como essa, e a funcionalidade
tende a ser simples. Escrever o teste depois, portanto,
no ser to diferente de escrever o teste antes.

O desenvolvedor maduro leva em considerao a sua


experincia, e entende bem as vantagens da prtica. E,
na hora certa, fazer uso dela.

Qual a diferena entre fazer TDD


e escrever o teste depois?
Se pararmos para analisar, o grande responsvel pelo
aumento da qualidade interna e externa no o TDD,
mas sim o teste automatizado, produzido perante o uso
da prtica. A pergunta comum justamente ento: Qual
a diferena entre fazer TDD e escrever o teste depois?
O desenvolvedor obtm feedback do teste. A diferena
justamente na quantidade de feedback. Quando o
desenvolvedor escreve os testes somente ao acabar a
implementao do cdigo de produo, ele passou muito
tempo sem retorno. Afinal, escrever o cdigo de produo
leva tempo. Ao praticar TDD, o desenvolvedor divide seu
trabalho em pequenas etapas. Ele escreve um pequeno
teste, e implementa um pedao da funcionalidade. E
repete. A cada teste escrito, o desenvolvedor ganha
feedback.
Quanto mais cedo o desenvolvedor receber feedback,
melhor. Quando se tem muito cdigo j escrito,
mudanas podem ser trabalhosas e custar caro. Ao
contrrio, quanto menos cdigo escrito, menor ser o
custo de mudana. E justamente isso que acontece com

praticantes de TDD: eles recebem feedback no momento


em que mudar ainda barato.
A figura abaixo exemplifica a diferena entre a
quantidade de feedback de um desenvolvedor que pratica
TDD e de um desenvolvedor que escreve testes ao final.

BENEFCIOS
Serei mais ou menos produtivo?
Assim como muitas das prticas geis, difcil ver os
benefcios quando no se faz uso dela. A primeira reao
da maioria das pessoas : "Mas agora eu gastarei boa
parte do meu tempo escrevendo testes? Isso no pode ser
produtivo!"
A resposta para a pergunta : sim, o desenvolvedor
gastar boa parte do seu tempo escrevendo cdigo de
testes. Mas isso no quer dizer que ele seja menos
produtivo por causa disso.
Antes de partir para argumentos, necessrio definirmos
o que ser produtivo. Para muitos, produtividade
simplesmente a quantidade de linhas de cdigo de
produo que so escritas por dia. Aqui, a definio de
produtividade ser linhas de cdigo escritas com
qualidade, de fcil manuteno, e que do pouco (ou
nada) retrabalho.
Para compararmos as vantagens da escrita de testes
automatizados, usarei o contra-exemplo: o teste manual.
O dia-a-dia do desenvolvedor que faz teste manual algo
parecido com isso: ele programa a funcionalidade
(geralmente toda ela de uma vez) e roda a aplicao.
Com a aplicao de p, ele faz o primeiro teste manual,
navegando pela aplicao e digitando os diversos dados

de entrada necessrios para fazer o teste. Muito


provavelmente o software no funcionar de acordo.
Ele ento obrigado a procurar pelo problema, lendo as
300 linhas de cdigo que escreveu, ou mesmo debugando.
Debugar a atividade onde o desenvolvedor executa linha
por linha de cdigo e v o resultado. Ambas as atividades
claramente desperdiam um tempo imenso do
desenvolvedor.
Em algum momento, o desenvolvedor encontrar o
problema. Ele o corrigir, e a repetir todo o processo:
subir a aplicao e far o teste manual. Muito
provavelmente outro problema aparecer. Dessa vez em
um ponto mais adiante da regra de negcio, claro. Ele
ento novamente repetir o processo.
Veja o quanto isso demorado e caro. O desenvolvedor
que faz teste manual repete o mesmo teste vrias vezes
por dia. O desenvolvedor que o automatiza gasta seu
tempo apenas uma vez. Na prxima vez, o teste ser
executado pela mquina em poucos milissegundos.
Mais ainda, sempre que o desenvolvedor precisar testar
novamente no futuro, ele o far de maneira manual,
gastando tempo. J o desenvolvedor que tem testes
automatizados, apenas executar sua bateria de testes.
Ela durar pra sempre e poder ser executada quantas
vezes quiser.

Ou seja, o desenvolvedor que escreve testes


automatizados gasta tempo com isso. Mas ele gasta
tempo de maneira inteligente. Hoje, o desenvolvedor que
faz teste manual tambm gasta muito tempo com testes,
mas de maneira errada, improdutiva. A mdio prazo, esse
desenvolvedor gastar mais tempo testando a mesma
funcionalidade do que o que foi esperto e os automatizou
desde o comeo. tudo uma questo de pensar a mdio
prazo.

ESTUDOS CIENTFICOS
Algum j fez estudos formais
sobre isso?
difcil acreditar em tudo que foi dito at agora, no?
Pois bem, para isso que servem trabalhos cientficos.
Para que fatos sejam separados de meros folclores.
Podemos separar estudos sobre TDD em 2 categorias
diferentes. Aqueles que olham TDD como uma prtica de
teste de software, e por consequncia avaliam os efeitos
dele na qualidade externa do software; e aqueles que
olham TDD como uma prtica de design e esto
preocupados com os efeitos dele na qualidade interna do
sistema.
Nos ltimos anos, a comunidade acadmica vem rodando
diversos experimentos para tentar mostrar de maneira
emprica que TDD realmente ajuda no processo de
desenvolvimento de software. Alguns desses estudos so
feitos por professores bastante conhecidos na
comunidade, como a prof. Laurie Williams1 (North
Carolina State University) e o prof. David Janzen
2
(California Polytechnic State University).
Esses estudos nos mostram que desenvolvedores que
praticam TDD gastam menos tempo debugando, escrevem
1
2

http://collaboration.csc.ncsu.edu/laurie/
http://users.csc.calpoly.edu/~djanzen/

mais testes automatizados para uma funcionalidade, e


defeitos so encontrados mais rapidamente, do que por
aqueles que no praticam TDD. Em termos de qualidade
interna, os estudos mostram que os desenvolvedores tem
uma forte percepo de que a prtica os ajuda a pensar
melhor sobre seu projeto de classes.
Voc pode ler muitos desses estudos com mais detalhes
em um post do meu blog, chamado TDD Realmente
Ajuda?3.

http://www.aniche.com.br/2010/04/tdd-realmenteajuda/

REFERNCIAS
Onde posso ler mais sobre isso?
Livros sobre TDD, apesar de no serem muitos, so bons.
Todos so bastante tcnicos, e devem ser lidos apenas
por desenvolvedores.
O primeiro livro sobre o assunto, escrito pelo Kent Beck,
Test-Driven Development: By Example4 um livro para
iniciantes. Ao longo dele, o autor desenvolve duas classes
do comeo ao fim, e explica passo-a-passo como TDD
feito. Os exemplos so bem minimalistas, mas um
excelente primeiro contato com a prtica.
Outro livro importante para aqueles que querem se
aprofundar o Growing Object-Oriented Software,
Guided by Tests5, escritos pelos excelentssimos autores
Steve Freeman e Nat Pryce. Esse um livro mais pesado;
os exemplos so maiores e eles discutem bastante sobre
como uma aplicao do zero deve ser criada a partir da
prtica de TDD. Apesar dos exemplos fazerem uso de
Swing, e o leitor encontra por muitas vezes extensas
listas de cdigo, um livro que vale a pena ser lido, caso
o desenvolvedor seja mais maduro.

http://www.amazon.com/Test-Driven-Development-ByExample/dp/0321146530
5
http://www.amazon.com/Growing-Object-OrientedSoftware-Guided-Tests/dp/0321503627

Um livro menos popular, mas tambm interessante o


Test-Driven Development: A Practical Guide6, do Dave
Astels. Ele tambm d exemplo de uma aplicao do
zero, e introduz conceitos interessantes como Mock
Objects.
Alm disso, o primeiro livro em portugus brasileiro sobre
o assunto, TDD: Teste e Design no Mundo Real7, escrito
por Maurcio Aniche, uma boa opo para aqueles que
querem ver no mesmo livro, exemplos bsicos para quem
est comeando, e exemplos mais avanados sobre a
relao entre TDD e design de classes. O livro foi baseado
em sua pesquisa de mestrado sobre o assunto.
Existe tambm muito material informal sobre o assunto.
O prprio blog do Aniche8, e o blog da Caelum9 possuem
bons textos. Abaixo uma pequena relao desses posts:
Perguntas e Respostas sobre TDD
http://www.aniche.com.br/2014/02/perguntas-e-respostas-sobretdd/

Bate papo sobre TDD na Caelum


http://www.aniche.com.br/2013/09/bate-papo-sobre-tdd-nacaelum/

http://www.amazon.com/Test-Driven-DevelopmentPractical-Guide/dp/0131016490
7
http://www.tddnomundoreal.com.br/
8
http://www.aniche.com.br/
9
http://blog.caelum.com.br

Dependncia de cenrios em testes de sistema


http://www.aniche.com.br/2013/04/dependencia-de-cenarios-emtestes-de-sistema/

Quantidade de Asserts no Teste


http://www.aniche.com.br/2013/04/quantidade-de-asserts-noteste/

Testando datas e mtodos estticos


http://www.aniche.com.br/2011/09/testando-datas-e-metodosestaticos/

Ser que eu preciso de 100% de cobertura de cdigo?


http://www.aniche.com.br/2011/02/sera-que-eu-preciso-de-100de-cobertura-de-testes/

Um pequeno estudo sobre asseres em testes


http://www.aniche.com.br/2011/01/um-pequeno-estudo-sobreassercoes-em-testes/

TDD, e no DDT
http://www.aniche.com.br/2010/12/eh-tdd-e-nao-ddt/

Criando cenrios de teste com Fixture Factory


http://blog.caelum.com.br/criando-cenarios-de-teste-com-fixturefactory/

O que a quantidade de asserts em um teste nos diz


sobre o cdigo?
http://blog.caelum.com.br/o-que-a-quantidade-de-asserts-em-umteste-nos-diz-sobre-o-codigo/

Facilitando a manuteno dos testes ao diminuir o


acoplamento com o cdigo
http://blog.caelum.com.br/facilitando-a-manutencao-dos-testesao-diminuir-o-acoplamento-com-o-codigo/

TDD e sua influncia no acoplamento e coeso


http://blog.caelum.com.br/tdd-e-sua-influencia-no-acoplamentoe-coesao/

Ganhando ou perdendo tempo com testes de unidade


http://blog.caelum.com.br/perdendo-ou-ganhando-tempo-comtestes-de-unidade/

Alm disso, Maurcio Aniche tambm tem diversas


publicaes cientficas10 sobre o assunto.

10

http://www.aniche.com.br/publications

TREINAMENTOS
Como treinar minha equipe?
Muitas vezes a melhor maneira de introduzir uma nova
prtica de desenvolvimento para a equipe trazendo
algum com mais experincia sobre o assunto, para
ensinar, discutir e buscar a melhor maneira para
introduzi-la no processo atual de desenvolvimento de
software.
A Caelum oferece treinamentos online e presencial sobre
o assunto. Os cursos oferecidos, bem como as ementas,
podem ser vistas na pgina da trilha de testes do Alura11,
o portal de ensino a distncia da Caelum.
Maurcio Aniche tambm palestrante sobre o assunto
nos mais diversos eventos brasileiros de desenvolvimento
de software, como QCON e Agile Brazil. Ele tambm d
workshops sobre o assunto para empresas privadas e
pblicas.
Entre em contato (mauricio.aniche@caelum.com.br).

11

http://www.alura.com.br/trilha/testes

VERSO
Verses do documento
Agosto/2014: Reviso do documento;
Abril/2014: Verso inicial do documento.

SOBRE O AUTOR
Maurcio Aniche mestre em Cincia da Computao pela
Universidade de So Paulo, onde pesquisou sobre os reais
efeitos da prtica de TDD no design de classes.
Atualmente aluno de doutorado pelo mesmo instituto.
Mauricio opta por ter um p no mundo da indstria e
outro no mundo da academia. J palestrou em diversos
eventos da indstria como QCON, Agile Brazil, .NET
Architects, e j publicou em conferncias acadmicas
nacionais e internacionais como TDD2010 (Paris), Agile
2011 (EUA), WBMA 2011 (Brasil). O mestrado fez mal a
ele, j que ele deixou de acreditar em post de blogs e
twitters de aficcionados pelas metodologias geis.
tambm autor do livro TDD: Teste e Design no Mundo
Real, o livro brasileiro mais popular sobre o assunto.

ORGANIZADORES
MAURCIO ANICHE
ANTNIO MILESI BASTOS

ALURA
Cursos online de tecnologia

CAELUM
Curso de Java, Curso de Android, Curso de JavaScript,
Curso de .NET, Curso de Agile, Curso de HTML e CSS

CASA DO CDIGO
Conhea tambm os livros da Casa do Cdigo