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 http://collaboration.csc.ncsu.edu/laurie/ 2 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.

3 http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/

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.

4 http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530 5 http://www.amazon.com/Growing-Object-Oriented-Software-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-sobre-tdd/

Bate papo sobre TDD na Caelum http://www.aniche.com.br/2013/09/bate-papo-sobre-tdd-na-caelum/

6 http://www.amazon.com/Test-Driven-Development-Practical-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-em-testes-de-sistema/

Quantidade de Asserts no Teste http://www.aniche.com.br/2013/04/quantidade-de-asserts-no-teste/

Testando datas e mtodos estticos http://www.aniche.com.br/2011/09/testando-datas-e-metodos-estaticos/

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

Um pequeno estudo sobre asseres em testes http://www.aniche.com.br/2011/01/um-pequeno-estudo-sobre-assercoes-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-fixture-factory/

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-um-teste-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-testes-ao-diminuir-o-acoplamento-com-o-codigo/

TDD e sua influncia no acoplamento e coeso http://blog.caelum.com.br/tdd-e-sua-influencia-no-acoplamento-e-coesao/

Ganhando ou perdendo tempo com testes de unidade http://blog.caelum.com.br/perdendo-ou-ganhando-tempo-com-testes-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