Desenvolvimento_de_Software_Orientado.pdf

Elogios a Desenvolvimento de Software Orientado a Objetos, Guiado por Testes

Os autores deste livro lideraram uma revoluo na arte de programao, controlando o ambiente no qual o software cresce. A placa de Petri deles o objeto simulado e o microscpio o teste de unidade. Este livro pode lhes mostrar como essas ferramentas apresentam a capacidade de repetio de seu trabalho, que poderia causar inveja em qualquer cientista.

Ward Cunningham

Finalmente um livro, repleto de cdigo, que expe a profunda simbiose entre TDD (Test-Driven Development Desenvolvimento Guiado por Testes) e OOD (Object-Oriented Design Projeto Orientado a Objeto). Os autores, pioneiros no desenvolvimento guiado por teste, rechearam o livro com princpios, prticas, heurstica e, melhor de tudo, anedotas oriundas de dcadas de experincia profissional. Cada artfice de software vai querer examinar minuciosamente os captulos de exemplos trabalhados e estudar os princpios avanados de teste e projeto. Este para ser guardado.

Robert C. Martin

Muitas vezes, o projeto discutido detalhadamente, mas sem empirismo. A testagem normalmente promovida, porm de acordo com a definio estreita de qualidade que s se refere presena ou ausncia de defeitos. Ambas as perspectivas so valiosas, mas cada uma delas oferece pouco mais do que o som de um aplauso. Steve e Nat juntam as duas mos no que merece e que pode ser mais bem descrito como aplauso. Com clareza, razo e humor, a fora deles mostra uma viso de projeto, testagem, cdigo, objetos, prtica e o processo que instigante, objetivo e transborda de perspiccia.

Kevlin Henney, coautor de Pattern-Oriented SoftwareArchitecture e 97 Things Every Programmer Should Know

Steve e Nat escreveram um livro maravilhoso no qual compartilham a habilidade deles em software com o restante do mundo. Este um livro que deve ser estudado, ao invs de lido, e aqueles que empreenderem tempo e energia neste sentido sero recompensados com habilidades de desenvolvimento superiores.

David Vydra, editor, testdriven.com

Este livro apresenta uma viso nica de desenvolvimento guiado por teste. Ele descreve a forma madura de um esforo alternativo em TDD que surgiu em Londres, no incio dos anos 2000, caracterizado por uma abordagem totalmente de ponta a ponta e uma nfase profunda quanto ao aspecto da mensagem de objetos. Se voc quiser ser um especialista na arte de TDD, precisa entender as ideias deste livro.

Michael Feathers

Com este livro voc aprender com os mestres o ritmo, as nuances de pensamento e as prticas eficazes de programao para aplicativos incrementais orientados a objeto bem-projetados.

Rebecca Wirfs-Brock

D

S

Steve Freeman

Nat Pryce

O O,G T

Rio de Janeiro, 2012

D

S

Steve Freeman

Nat Pryce

O O,G T

Para Paola, por todo o seu apoio; para Philip, que, s vezes, se omitiu Steve

Para Lamaan, que me aguentou enquanto eu escrevia este livro, e para Oliver Tarek, que no me aguentou

Nat

ix

Sumrio

Introduo..................................................................................................................xvii

Prefcio .......................................................................................................................xix

Agradecimentos ........................................................................................................xxiii

Sobre os Autores ........................................................................................................xxv

Parte I: Introduo.........................................................................................................1

Captulo 1: Qual a Finalidade do Desenvolvimento Guiado por Teste?.................3Desenvolvimento de Software como um Processo de Aprendizado ...................... 3O Retorno a Ferramenta Fundamental .................................................................. 4Prticas que Encorajam Mudanas ........................................................................... 5Resumo do Desenvolvimento Guiado por Teste ..................................................... 6Testagem de Ponta a Ponta ........................................................................................ 8O Quadro Geral ............................................................................................................ 7Nveis de Testagem ..................................................................................................... 9Qualidade Externa e Interna .................................................................................... 10

Captulo 2: Desenvolvimento Guiado por Teste com Objetos ................................13Uma Teia de Objetos ................................................................................................. 13Valores e Objetos ...................................................................................................... 13Siga as Mensagens .................................................................................................... 14Diga, No Pergunte ................................................................................................... 17Mas Pergunte s Vezes ............................................................................................ 17Teste de Unidade de Objetos Colaboradores .......................................................... 18Assistncia para TDD com Objetos Simulados ....................................................... 19

Sumriox

Captulo 3: Uma Introduo s Ferramentas ........................................................21Interrompa-me Se Tiver Ouvido Isto Antes ........................................................... 21Uma Pequena Introduo a JUnit 4 ......................................................................... 21Hamcrest Matchers e assertThat() .......................................................................... 24jMock2: Objetos Simulados ...................................................................................... 25

Parte II: O Processo de Desenvolvimento Guiado por Teste .........................................29

Captulo 4: Pontap Inicial para o Ciclo Guiado por Teste ....................................31Introduo ................................................................................................................. 31Primeiro, Teste um Esqueleto Ambulante.............................................................. 32Decidindo a Forma do Esqueleto Ambulante ......................................................... 33Monte Fontes de Retorno ......................................................................................... 35Exponha Cedo as Incertezas .................................................................................... 36

Captulo 5: Mantendo o Ciclo Guiado por Teste ....................................................39Introduo ................................................................................................................. 39Inicie Cada Recurso com um Teste de Aceitao ................................................... 39Separe Testes que Medem Progresso Daqueles que Detectam Regresses ......... 40Inicie Testes com o Caso Bem-sucedido Mais Simples .......................................... 41Escreva o Teste Que Voc Desejaria Ler ................................................................. 42Observe o Teste Falhar ............................................................................................. 42Desenvolva dos Inputs para os Outputs.................................................................. 43Comportamento de Teste de Unidade, No Mtodos ............................................ 43Escute os Testes......................................................................................................... 44Sintonizando o Ciclo ................................................................................................. 45

Captulo 6: Estilo Orientado a Objeto ...................................................................47Introduo ................................................................................................................. 47Projetando para a Sustentabilidade ........................................................................ 47Internos vs. Pares...................................................................................................... 50Sem Es, Ou ou Mas .................................................................................................... 51Esteretipos dos Pares do Objeto ............................................................................ 52Composio Mais Simples Que a Soma de Suas Partes ......................................... 53Independncia de Contexto ..................................................................................... 54Ocultando as Informaes Corretas ........................................................................ 55Uma Viso Dogmtica .............................................................................................. 56

Captulo 7: Obtendo o Projeto Orientado a Objeto ................................................57Como Escrever um Teste Primeiro Ajuda o Projeto .............................................. 57Comunicao Acima de Classificao...................................................................... 58Tipos de Valor ........................................................................................................... 59De Onde Vm os Objetos? ......................................................................................... 60Identifique Relaes com Interfaces ....................................................................... 63Refatore Tambm as Interfaces ............................................................................... 63Combine Objetos para Descrever o Comportamento do Sistema ........................ 64Construindo para Programao de Nvel Mais Alto .............................................. 65E Quanto s Classes? ................................................................................................. 67

Sumrio xi

Captulo 8: Montando a partir de Cdigo de Terceiros .........................................69Introduo ................................................................................................................. 69Apenas Simule os Tipos que Voc Possui ............................................................... 69Objetos de Aplicativo Simulados em Testes de Integrao .................................. 71

Parte II: Um Exemplo Trabalhado ................................................................................73

Captulo 9: O Auction Sniper na prtica ..............................................................75Comeando do Incio ................................................................................................ 75Comunicao com um Leilo ................................................................................... 78Como Chegar L Com Segurana ............................................................................. 79Isso No Real........................................................................................................... 81

Captulo 10: O Esqueleto Ambulante ....................................................................83Tire o Esqueleto do Armrio .................................................................................... 83O Nosso Primeiro Teste ............................................................................................ 84Algumas Escolhas Iniciais ........................................................................................ 86

Captulo 11: Passando o Primeiro Teste ...............................................................89Como Montar o Aparelho de Teste ......................................................................... 89Falhando e Passando o Teste ................................................................................... 95O Mnimo Necessrio .............................................................................................. 102

Captulo 12: Preparao Para o Lance ................................................................ 105Uma Introduo ao Mercado ................................................................................. 105Um Teste Para Dar o Lance .................................................................................... 106O AuctionMessageTranslator ................................................................................ 112Desempacotando uma Mensagem de Preo ......................................................... 118Finalize o Trabalho ................................................................................................. 121

Captulo 13: O Sniper D um Lance .................................................................... 123Apresentando o AuctionSniper ............................................................................. 123Como Enviar um Lance ........................................................................................... 126Como Arrumar a Implementao .......................................................................... 131Protele Decises ...................................................................................................... 136Projeto Emergente .................................................................................................. 137

Captulo 14: O Sniper Vence o Leilo .................................................................. 139Primeiro, um Teste que Falha ................................................................................ 139Quem Sabe sobre os Arrematadores? ................................................................... 140O Sniper Tem Mais a Dizer ..................................................................................... 143O Sniper Adquire Algum Estado ........................................................................... 144O Sniper Vence ........................................................................................................ 146Progredindo com Estabilidade .............................................................................. 148

Captulo 15: Rumo a uma Interface Real de Usurio .......................................... 149Uma Implementao Mais Realista ....................................................................... 149Exibindo Detalhes de Preo ................................................................................... 152Simplificando Eventos do Sniper .......................................................................... 159

Sumrioxii

Completando a Tarefa ............................................................................................ 164Polimento Final ....................................................................................................... 168Observaes ............................................................................................................. 171

Captulo 16: Sniper para Itens mltiplos ............................................................ 175Teste por Itens Mltiplos ....................................................................................... 175Acrescentando Itens atravs da Interface de Usurio ........................................ 183Observaes ............................................................................................................. 189

Captulo 17: Desmontando a Main ...................................................................... 191Encontrando um Papel .......................................................................................... 191Extraindo o Chat ..................................................................................................... 192Extraindo a Conexo ............................................................................................... 195Extraindo o SnipersTableModel ............................................................................ 197Observaes ............................................................................................................. 201

Captulo 18: Preenchendo os Detalhes ............................................................... 205Um Aplicativo Mais til ......................................................................................... 205Pare Quando J Tivermos o Suficiente ................................................................. 205Observaes ............................................................................................................. 212

Captulo 19: Lidando com a Falha ...................................................................... 215E Se No Funcionar? ............................................................................................... 215Detectando a Falha ................................................................................................. 217Exibindo a Falha ...................................................................................................... 218Desconectando o Sniper ......................................................................................... 219Registrando a Falha ................................................................................................ 221Observaes ............................................................................................................. 225

Parte IV: Desenvolvimento Sustentvel Guiado por Teste.......................................... 227

Captulo 20: Escutando os Testes ........................................................................ 229Introduo ............................................................................................................... 229Preciso Simular um Objeto o Qual No Posso Substituir (Sem Mgica) ............ 230Criar Logs um Recurso ........................................................................................ 233No Simule Valores ................................................................................................. 237Construtor Inflado .................................................................................................. 238Objeto Confuso ........................................................................................................ 240Muitas Dependncias ............................................................................................. 241Muitas Expectativas ................................................................................................ 242O Que Nos Diro os Testes (Se Estivermos Atentos) ............................................ 244

Captulo 21: Legibilidade do Teste .............................................................................. 247Introduo ............................................................................................................... 247Nomes de Teste Descrevem Recursos ................................................................... 248Estrutura de Teste Cannica .................................................................................. 251Aperfeioe o Cdigo de Teste ................................................................................ 252Asseres e Expectativas ........................................................................................ 254Literais e Variveis ................................................................................................. 255

Sumrio xiii

Captulo 22: Construindo Dados de Teste Complexos ......................................... 257Introduo ............................................................................................................... 257Montadores de Dados de Teste .............................................................................. 258Criando Objetos Similares ...................................................................................... 259Combinando Montadores ....................................................................................... 261Enfatizando o Modelo de Domnio com Mtodos de Fbrica ............................. 261Removendo a Duplicao no Ponto de Utilizao ............................................... 262Primeiro a Comunicao ........................................................................................ 264

Captulo 23: Diagnstico de Teste ...................................................................... 267Projete para Falhar ................................................................................................. 267Testes Pequenos, Direcionados, Bem-Nomeados ................................................ 268Mensagens de Assero Explanatrias ................................................................. 268Destaque os Detalhes com Matchers..................................................................... 268Valor Autodescritivo .............................................................................................. 269Valor Obviamente Criado ....................................................................................... 270Objeto Rastreador ................................................................................................... 270Declare Explicitamente Que as Expectativas Foram Alcanadas ....................... 271Diagnsticos So Recursos de Primeira Classe .................................................... 271

Captulo 24: Flexibilidade do Teste .................................................................... 273Introduo ............................................................................................................... 273Teste para Informao, No para Representao ................................................ 274Asseres Exatas ..................................................................................................... 275Expectativas Exatas ................................................................................................ 277Ignorando Objetos Irrelevantes ............................................................................ 279Objetos Cobaia ......................................................................................................... 284

Parte V: Tpicos Avanados ....................................................................................... 287

Captulo 25: Testando a Persistncia .................................................................. 289Introduo ............................................................................................................... 289Isole Testes Que Afetam o Estado Persistente ..................................................... 290Torne Explcitos Os Limites de Transao dos Testes ........................................ 292Testando um Objeto Que Executa Operaes de Persistncia ............................ 294Teste Que Comprova Que Objetos Podem Ser Persistidos .................................. 297Mas, Testes de Banco de Dados So L-e-n-t-o-s! .................................................. 300

Captulo 26: Testagem de Unidade e Threads ..................................................... 301Introduo ............................................................................................................... 301Separando Funcionalidade e Poltica de Simultaneidade................................... 302Sincronizao da Testagem de Unidade ............................................................... 306Testando a Resistncia de Objetos Passivos ......................................................... 311Sincronizando a Thread de Teste com a Thread em Segundo Plano ................ 312As Limitaes dos Testes de Resistncia de Unidade .......................................... 313

Captulo 27: Testando o Cdigo Assncrono........................................................ 315Introduo ............................................................................................................... 315Amostrando ou Ouvindo ........................................................................................ 316Duas Implementaes............................................................................................. 318

Sumrioxiv

Testes de Fuga ......................................................................................................... 322Atualizaes Perdidas ............................................................................................. 323Testando Que Ao No Causa Efeito .................................................................... 325Diferencie Sincronizaes de Asseres ............................................................... 326Externalize as Fontes de Evento ............................................................................ 326

Posfcio: Uma Breve Histria dos Objetos Simulados ................................................. 329

Apndice A: Cheat Sheet do jMock2 ........................................................................... 335

Apndice B: Escrevendo um Matcher Hamcrest ......................................................... 343

Bibliografia ................................................................................................................ 347

ndice ......................................................................................................................... 349

Desenvolvimento de Software Orientado a Objetos, Guiado por Testes

O material a seguir est disponibilizado na pgina oficial do livro, em ingls: http://growing-object-oriented-software.com/code.html.

Exemplos de Cdigo

O exemplo trabalhado (Auction Sniper)

O cdigo para o exemplo trabalhado, do Auction Sniper, que est presente na arte III do livro, est disponvel em vrias linguagens de programao:

s /CDIGOFONTEORIGINALEM*AVADOLIVROCOMARQUIVOSDOPROJETO%CLIPSEs 0ORTA2UBYPOR"RIAN-ARICKs 0ORTA3CALAPOR3PIROS4ZAVELLASs 0ORTA#POR$AVID'ADDs 0ORTA'ROOVYPOR0AUL+ING

Exemplos presentes nas partes Desenvolvimento Sustentvel Guiado por Teste e Tpicos Avanados

Exemplos de cdigo menores de outros captulos, incluindo Diagnstico de Teste, Flexibilidade do Teste, Testando a Persistncia e Testando o Cdigo Assncrono:

s #DIGOFONTE*AVACOMARQUIVOSDOPROJETO)NTELLI*

Um tipo Maybe

Um tipo Maybe, como mencionado no captulo de Flexibilidade.

s #DIGOFONTE*AVACOMARQUIVOSDOPROJETO)NTELLI*

Ferramentas

Voc precisar do Git para ver qualquer exemplo de cdigo. A verso gratuita do IntelliJ j vem com suporte ao Git como parte da instalao padro.

Para explorar o cdigo Java voc pode usar as IDEs do Eclipse e/ou IntelliJ.

xvii

Introduo

Kent Beck

Um dos dilemas impostos pelo movimento na direo de ciclos de lanamentos cada vez menores como lanar mais software em menos tempo e continuar a lanar, indefi-nidamente. Impe-se uma nova perspectiva para solucionar esse dilema. necessrio mais do que uma troca de tcnicas.

Desenvolvimento de Software Orientado a Objetos, Guiado por Testes apresenta esta nova perspectiva. E se o software no fosse feito, como montamos um avio de papel dobrando-o e fazendo-o voar para longe? E se, ao invs disso, tratssemos o software mais como uma planta valiosa, produtiva, a ser alimentada, podada, ceifada, fertili-zada e regada? Os fazendeiros tradicionais sabem como manter as plantas produtivas por dcadas ou mesmo sculos. Como o desenvolvimento de software seria diferente se tratssemos os nossos programas da mesma maneira?

Estou muito impressionado pela forma como este livro apresenta tanto a filosofia quanto a mecnica da tal mudana de perspectiva. Ele escrito por profissionais que codificam bem e ensinam aos outros a codificar. A partir dele, possvel aprender tanto como programar para manter a produtividade quanto olhar de outra forma para os seus programas.

O estilo de desenvolvimento guiado por testes apresentado aqui diferente da minha prtica. Eu ainda no consigo articular a diferena mas aprendi, a partir da apresentao clara e confiante das tcnicas dos autores. A diversidade de diale-tos me deu uma nova fonte de ideias para refinar mais o meu prprio progresso. Desenvolvimento de Software Orientado a Objetos, Guiado por Testes mostra um sistema de desenvolvimento coerente e consistente, em que diferentes tcnicas auxiliam umas s outras.

Eu o convido a ler Desenvolvimento de Software Orientado a Objetos, Guiado por Testes, a acompanhar os exemplos, aprender a maneira dos autores pensar sobre programao e como eles programam. A experincia enriquecer o seu estilo de desenvolver software, ir ajud-lo a programar e, com a mesma importncia, a encarar os seus programas de maneira diferente.

xix

Prefcio

De que trata este livro?

Este livro um guia prtico melhor forma que encontramos de escrever software orientado a objeto: test-driven development (TDD desenvolvimento guiado por teste). Ele descreve o processo que seguimos, os princpios do projeto pelos quais lutamos e as ferramentas que usamos. Ele baseia-se em nossas dcadas de experincia, traba-lhando e aprendendo com alguns dos melhores programadores do mundo.

No livro, apresentamos algumas das perguntas e confuses que vemos surgir a cada projeto. Como encaixo desenvolvimento guiado por teste em um projeto de software? Por onde eu comeo? Por que eu deveria escrever ambos os testes de unidade e de ponta a ponta? O que significa dizer testes guiam desenvolvimento? Como eu testo o difcil recurso X?

Este livro tambm trata muito de projeto e de como nossa forma de projetar auxi-lia a nossa abordagem a TDD. Se existe uma coisa que aprendemos que o desen-volvimento guiado por teste funciona melhor quando tomado como um todo. Vimos equipes que podem executar as prticas brutas (escrever e rodar testes), mas que lutam com o resultado, porque no adotaram tambm os processos subjacentes mais profundos.

Por que Cultivando Software Orientado a Objeto?

Usamos o termo cultivar, pois ele transmite uma ideia de como desenvolvemos de forma crescente. H algo que funciona o tempo todo, garantindo que o cdigo seja sem-pre to bem estruturado quanto possvel e cuidadosamente testado. Nada mais parece ser to eficiente quanto apresentar sistemas que funcionam. Como escreveu John Gall em [Gall03], Um sistema complexo que funciona invariavelmente considerado como evoludo de um sistema simples que funciona.

Prefcioxx

Cultivar tambm enseja a qualidade biolgica que vemos em um software de boa qualidade: o sentido de coerncia em cada nvel de estrutura. Ele se associa nossa abordagem de orientao a objeto que acompanha o conceito de Alan Kay,1 de objetos como sendo semelhantes a clulas biolgicas que enviam mensagens entre si.

Por que Guiado por Testes?

Escrevemos os testes primeiro, pois acreditamos que nos ajude a escrever cdigos melho-res. Escrever um teste antes nos obriga a esclarecer as nossas intenes e no comeamos a etapa seguinte do trabalho at termos uma descrio ntida do que ele deveria fazer. O processo de escrever um teste nos ajuda a ver quando um projeto rgido demais ou sem foco. Ento, quando queremos prosseguir e corrigir um projeto imperfeito, os testes nos do uma rede de segurana de cobertura contra retrocesso.

Usamos o termo guiado porque a tcnica ainda exige habilidade e experincia. Descobrimos que o desenvolvimento guiado por teste uma ferramenta de apoio efi-ciente ao projeto uma vez que aprendemos a desenvolver de forma incremental e a escutar os testes. Como qualquer atividade sria de projeto, TDD requer entendi-mento e esforo contnuo para funcionar.

Vimos equipes que escrevem testes e cdigo quase ao mesmo tempo (e at equipes que escrevem os testes primeiro), em que o cdigo uma confuso e os testes apenas aumentam o custo de manuteno. Eles comearam, mas ainda no aprenderam que o truque, como sugere o ttulo do livro, deixar que os testes guiem o desenvolvimento. Use o contedo dos testes para permanecer focalizado em progredir e na reao aos testes, de modo a aumentar a qualidade do sistema.

E quanto a Objetos Simulados?

A nossa motivao original para escrever este livro foi finalmente explicar a tcnica de usar mock objects2 (objetos simulados), os quais normalmente so mal compreen-didos. Na medida que nos aprofundamos na escrita, percebemos que a descoberta e o uso dos objetos simulados pela nossa comunidade era, na verdade, uma expresso da nossa abordagem ao escrever software; era parte de um quadro mais amplo.

No decorrer do livro, apresentaremos como funciona a tcnica de objetos simulados, usando a biblioteca jMock. Mais especificamente, mostraremos onde ela se encaixa no processo TDD e como faz sentido no contexto do desenvolvimento orientado a objeto.

Para quem este livro?

Escrevemos este livro para o leitor informado. Ele destinado aos programadores com experincia profissional, os quais provavelmente, ao menos, j viram desenvol-vimento guiado por teste. Ao escrever, imaginamos que estvamos explicando tcni-cas a um colega que ainda no tinha conhecimento delas.

1. Alan Kay foi um dos autores de Smalltalk e cunhou o termo object-oriented.

2. Objetos simulados so implementaes substitutas para testar como um objeto interage com seus vizinhos.

Prefcio xxi

De modo a dar espao ao material mais aprofundado que queramos abordar, par-timos do princpio de que o leitor tenha algum conhecimento dos conceitos e ferra-mentas bsicas; h outros livros que oferecem uma boa introduo a TDD.

Este um livro de Java?

Usamos a linguagem de programao Java ao longo de todo o livro, porque, por ser bem comum, imaginamos que os nossos leitores sejam capazes de, pelo menos, enten-der os exemplos. Sendo assim, o livro realmente sobre um conjunto de tcnicas que so aplicveis a qualquer ambiente orientado a objeto.

Se no estiver usando Java, h equivalentes das bibliotecas de teste e simulao que usamos (JUnit e jMock) em muitas outras linguagens, incluindo C#, Ruby, Python, Smalltalk, Objective-C e, impressionantemente, C++. Existem inclusive verses para lin-guagens mais distantes como Scala. H ainda outros frameworks de teste e simulao em Java.

Por que voc deveria nos ouvir?

Este livro destila nossas experincias ao longo de dcadas, incluindo quase dez anos de desenvolvimento guiado por testes. Durante esse tempo, usamos TDD em uma ampla gama de projetos: grandes sistemas orientados a mensagem de integrao de empreendimentos com uma interface web e apoiados em grades computacionais de mltiplos processadores; pequenos sistemas embutidos que tm que rodar em deze-nas de kilobytes de memria; jogos gratuitos usados como propaganda para sistemas crticos do negcio; e middleware de backend e servios de rede para aplicaes grfi-cas de desktop altamente interativas. Alm disso, temos ensinado e escrito sobre esse material em eventos e companhias ao redor do mundo.

Tambm nos beneficiamos da experincia de nossos colegas na comunidade de TDD, com sede em Londres. Ficamos muitas horas, durante e depois do trabalho, com nossas ideias sendo desafiadas e aprimoradas. Somos gratos pela oportunidade de trabalhar com colegas to animados (e questionadores).

O que h neste livro?

O livro tem seis partes:Parte I, Introduo, uma introduo de alto nvel ao desenvolvimento guiado

por teste, objetos simulados e projeto orientado a objeto dentro do contexto de um projeto de desenvolvimento de software. Tambm apresentamos alguns frameworks que usamos no restante do livro. Ainda que voc j esteja familiarizado com TDD, recomendamos que leia os Captulos 1 e 2, visto que eles descrevem a nossa aborda-gem ao desenvolvimento de software. Se o leitor estiver familiarizado com JUnit e jMock, possvel pular o resto da introduo.

Prefcioxxii

Parte II, O Processo de Desenvolvimento Guiado por Teste, descreve o pro-cesso de TDD, mostrando como iniciar e manter o progresso do desenvolvimento. Aprofundamo-nos na relao entre a nossa abordagem guiada por teste e programa-o orientada a objeto, mostrando como os princpios das duas tcnicas se apoiam. Por fim, abordamos como trabalhar com cdigo externo. Esta parte descreve os con-ceitos, a parte seguinte coloca-os para funcionar.

Parte III, Um Exemplo Trabalhado, um exemplo ampliado que d um gosto de como desenvolvemos um aplicativo orientado a objeto de uma maneira guiada por teste. Ao longo do processo, discutimos os equilbrios e as motivaes das deci-ses tomadas. Elaboramos um exemplo bem grande, porque queremos mostrar como alguns aspectos de TDD tornam-se mais significativos na medida em que o cdigo aumenta.

Parte IV, Desenvolvimento Sustentvel Guiado por Teste, descreve algumas prticas que mantm um sistema sustentvel. Atualmente, temos muito cuidado em manter uma base de cdigo limpa e expressiva, pois, com os anos, descobrimos o custo de deixar as coisas se perderem. Essa parte descreve algumas das prticas que adotamos e explica o motivo pelo qual o fizemos.

Parte V, Tpicos Avanados, aborda as reas onde TDD mais difcil: dados de teste complexos, persistncia e simultaneidade. Mostramos como lidamos com essas questes e como isso afeta o projeto do cdigo e testes.

Por fim, os apndices incluem algum material de apoio sobre jMock e Hamcrest.

O que no est neste livro?

Este um livro tcnico. Deixamos de fora todos os outros tpicos que fazem um projeto ser bem-sucedido, tais como organizao de equipe, gerenciamento de exi-gncias e design de produto. Adotar uma abordagem incremental guiada por teste para o desenvolvimento certamente tem uma relao estreita com a maneira como um projeto executado. TDD possibilita algumas novas atividades, tal como forneci-mento frequente e pode ser inutilizado por circunstncias organizacionais, como, por exemplo, o cancelamento precoce de um projeto ou a ausncia de comunicao de um grupo de acionistas. De novo, h muitos outros livros para dar conta desses tpicos.

xxiii

Agradecimentos

Os autores gostariam de agradecer a todos aqueles que ofereceram seu apoio e cola-borao durante a escrita deste livro. Para comear, Ken Beck e Greg Doench o enco-mendaram, e Dimitri Kirsanov e Alina Kirsanova (com incrvel pacincia) fizeram os retoques e o tornaram realidade.

Muitas outras pessoas maravilhosas nos ajudaram, tendo o trabalho de ler e revisar rascunhos ou simplesmente dando apoio e estmulo: Romilly Cocking, Jamie Dobson, Michael Feathers, Martin Fowler, Naresh Jain, Pete Keller, Tim Mackinnon, Duncan McGregor, Ivan Moore, Farshad Nayeri, Isaiah Perumalla, David Peterson, Nick Pomfret, J. B. Rainsberger, James Richardson, Lauren Schmitt, Douglas Squirrel, The Silicon Valley Patterns Group, Vladimir Trofimov, Daniel Wellman e Matt Wynne.

Agradecemos a Dave Denton, Jonathan Buck Rogers e Jim Kuo pelos trabalhos de modelagem.

Este livro e as tcnicas que descrevemos nele no existiriam sem o Extreme Tuesday Club (XTC), um grupo de reunio informal em Londres para os interessados em programao extrema e gil, alm do desenvolvimento guiado por teste. Somos profundamente gratos a todas as pessoas com as quais compartilhamos experincias, tcnicas, lies aprendidas e rodadas.

xxv

Sobre os Autores

Steve Freeman

Steve Freeman um consultor independente especializado em desenvolvimento do software Agile (http://www.m3p.co.uk - contedo em ingls). Junto com Nat Pryce, ele foi o vencedor do prmio Agile Alliance Gordon Pask 2006. Membro fundador do London Extreme Tuesday Club foi o presidente do primeiro London XP Day e organi-zador e apresentador frequente em conferncias internacionais. Steve trabalhou em uma ampla gama de organizaes e desenvolveu desde software de prateleira para a IBM a prottipo para os principais laboratrios de pesquisa. Steve tem PhD pela Cambridge University e diplomas em estatstica e msica. Steve mora em Londres, no Reino Unido.

Nat Pryce

Depois de terminar o seu PhD na Imperial College, Nat Pryce uniu-se ao boom do ponto-com, bem a tempo de v-lo estourar. Desde ento, ele tem trabalhado como programador, arquiteto, treinador e consultor em uma srie de setores, inclusive reportagens esportivas, marketing de comunicao, varejo, empresas de telecomu-nicao e finanas. Ele tambm participou de projetos acadmicos de pesquisa e, ocasionalmente, ministra aulas em universidade. Tendo adotado cedo XP (eXtreme Programming), ele escreveu ou colaborou em vrias bibliotecas de fonte aberta que suportam TDD e foi um dos organizadores e fundadores da conferncia London XP Day. Tambm se apresenta com frequncia em conferncias internacionais. Nat mora em Londres, no Reino Unido.

Parte I

Introduo

O Desenvolvimento Guiado por Teste (TDD) uma ideia ilusoriamente simples: escreva os testes para o seu cdigo antes de escrever o cdigo em si. Dizemos ilusoriamente simples porque isso transforma o papel da testagem no pro-cesso de desenvolvimento e desafia as suposies da nossa indstria quanto ao objetivo da testagem. O teste no mais apenas uma questo de esconder os defeitos dos usurios; ao contrrio, serve para ajudar a equipe a entender os recursos que os usurios precisam e fornecer tais recursos de maneira con-fivel e previsvel. Ao chegarmos s concluses, o TDD muda radicalmente a forma pela qual desenvolvemos software e, de acordo com nossa experincia, aperfeioa incrivelmente a qualidade dos sistemas que montamos, em especial a confiabilidade e a flexibilidade deles, em resposta s novas exigncias.

O desenvolvimento guiado por teste amplamente usado em abordagens de desenvolvimento de software gil. Ele uma prtica central de Extreme Programming (XP Programao Extrema) [Beck99], recomendado por Crystal Clear [Cockburn04] e, com frequncia, usado em projetos Scrum [Schwaber01]. Ns usamos TDD em cada projeto gil com os quais estivemos envolvidos e descobrimos usos para ele em projetos no geis. Descobrimos at que ele nos ajuda a progredir em projetos de pura pesquisa, em que a motiva-o explorar ideias ao invs de fornecer recursos.

3Captulo 1

Qual a Finalidade do Desenvolvimento Guiado por Teste?

Deve-se aprender fazendo; por mais que voc pense que sabe, no ter certeza at tentar.

Sfocles

Desenvolvimento de Software como um Processo de Aprendizado

Quase todos os projetos de software esto experimentando algo que ningum tenha feito antes (ou pelo menos, que ningum na organizao tenha realizado). Este algo pode se referir s pessoas envolvidas, ao domnio do aplicativo, tecnologia usada ou (mais provavelmente) combinao desses fatores. Apesar dos melhores esfor-os de nossa disciplina, todos, exceto os projetos mais rotineiros, tm elementos surpresa. Projetos interessantes aqueles que oferecem o maior benefcio em geral apresentam muitas surpresas.

Os desenvolvedores, muitas vezes, no compreendem totalmente as tecnologias que esto usando. Eles precisam aprender como funcionam os componentes enquanto finalizam o projeto. Ainda que eles tenham um bom conhecimento das tecnologias, novos aplicativos podem for-los a caminhos desconhecidos. Um sistema que combina muitos componentes significativos (que, na verdade, a maior parte do servio de um programador profissional) ser complexo demais para qualquer um entender todas as suas possibilidades.

Para clientes e usurios finais, a experincia pior. O processo de montar um sistema os obriga a verificar as suas organizaes mais atentamente do que antes. Geralmente, eles tm que negociar e codificar processos que, at agora, tinham se baseado em conveno e experincia.

Qualquer profissional envolvido em um projeto de software precisa aprender medida que ele progride. Para o projeto ser bem-sucedido, os envolvidos precisam tra-balhar juntos para entender o que eles devem conseguir, alm de identificar e solu-cionar mal entendidos pelo caminho. Todos eles sabem que haver mudanas, apenas no sabem quais. Eles precisam de um processo que os ajudar a lidar com a incerteza medida que suas experincias aumentam ou seja, antecipar mudanas imprevistas.

Captulo 1 Qual a Finalidade do Desenvolvimento Guiado por Teste? 4

O Retorno a Ferramenta Fundamental

Acreditamos que a melhor abordagem de uma equipe usar o retorno emprico para aprender sobre o sistema e o seu uso, e depois aplicar aquele aprendizado de volta ao sistema. Uma equipe precisa de ciclos repetidos de atividade. Em cada ciclo, ela acrescenta novos recursos e obtm o retorno em relao quantidade e qualidade do trabalho j realizado. Os membros da equipe dividem o trabalho em caixas de tempo, dentro das quais eles analisam, projetam, implementam e expem tantos recursos quantos puderem.

fundamental expor o trabalho finalizado em algum tipo de ambiente a cada ciclo. Toda vez que uma equipe faz isso, os seus membros tm a chance de conferir suas suposies em relao realidade. Eles podem avaliar o real progresso, detectar e corrigir quaisquer erros e adaptar o plano atual em resposta ao que aprenderam. Sem a exposio, o retorno no est completo.

Em nosso trabalho, aplicamos os ciclos de retorno em cada nvel de desenvolvi-mento, organizando projetos como um sistema de loops aninhados, variando de segundos a meses, como: programao par, testes de unidade, testes de aceitao, reunies dirias, iteraes, lanamentos e assim por diante. Cada loop expe o resul-tado da equipe quanto ao retorno emprico, de modo que a equipe possa descobrir e corrigir quaisquer erros ou concepes equivocadas. Os loops de retorno aninhados reforam uns aos outros; se uma discrepncia escapar de um loop interno, h boa possibilidade de que um loop externo a pegue.

Cada loop de retorno trata de aspectos diferentes do sistema e do processo de desenvolvimento. Os loops internos focalizam-se mais no detalhe tcnico: o que uma unidade de teste faz, se ela integra com o resto do sistema. Os loops mais externos so focados na organizao e na equipe: se o aplicativo serve s necessidades dos seus usurios, se a equipe to eficiente quanto poderia.

Quanto mais rpido conseguirmos retorno em relao a qualquer aspecto do pro-jeto, melhor. Muitas equipes em grandes organizaes podem lanar em poucas sema-nas. Algumas fazem lanamentos em poucos dias ou mesmo horas, o que aumenta e muito a oportunidade de receber e responder reao de usurios reais.

Desenvolvimento Incremental e Iterativo

%MUMPROJETOORGANIZADOCOMOUMCONJUNTODEloopsDERETORNOANINHADOSODESENVOLVIMENTOincrementalEiterativo/DESENVOLVIMENTOincrementalMONTAUMSISTEMARECURSOPORRECURSOAOINVSDEMONTARTODASASCAMADASECOMPONENTESEINTEGRLOSAOFINAL#ADARECURSOIMPLEMENTADOCOMOUMAhFATIAvDEPONTAAPONTAPORTODASASPARTESRELEVANTESDOSISTEMA/SISTEMAESTSEMPREINTEGRADOEPRONTOPARAEXPOSIO/DESENVOLVIMENTOiterativoREFINAPROGRESSIVAMENTEAIMPLEMENTAODERECURSOSEMRESPOSTAAORETORNOATQUEELESESTEJAMSATISFATRIOS

Prticas que Encorajam Mudanas 5

Prticas que Encorajam Mudanas

Descobrimos que precisamos de duas bases tcnicas se quisermos cultivar com con-fiabilidade um sistema e lidar com as mudanas imprevistas que sempre acontecem. Primeiramente, precisamos de testagens constantes para identificar os erros de regres-so, de modo a podermos acrescentar novos recursos sem romper aqueles j existen-tes. Em sistemas de qualquer tamanho interessante, a testagem manual costumeira simplesmente pouco prtica; portanto, precisamos automatiz-la tanto quanto possvel para reduzir os custos de montagem, exposio e modificao de verses do sistema.

Em segundo lugar, precisamos manter o cdigo o mais simples possvel para que ele seja mais fcil de compreender e modificar. Os desenvolvedores perdem muito mais tempo lendo cdigo do que os escrevendo; por isso que devemos otimizar.1 A simplicidade exige esforo, portanto, estamos constantemente refatorando [Fowler99] o nosso cdigo enquanto trabalhamos com ele para aperfeioar e simplificar o seu projeto, remover duplicao e garantir que ele expresse claramente sua funo. As sries de teste nos loops de retorno nos protegem contra os nossos prprios erros enquanto aperfeioamos (e, portanto, alteramos) o cdigo.

O problema que alguns desenvolvedores gostam de testar seus cdigos. Em muitos grupos de criao, escrever testes automatizados visto como um trabalho irreal se comparado ao acrscimo de recursos, e tambm enfadonho. A maioria das pessoas no to bem-sucedida como deveria quando considera um trabalho pouco inspirador.

O Test-Driven Development (Desenvolvimento Guiado por Teste) (TDD) altera essa situ-ao por completo. Escrevemos os nossos testes antes de escrever o cdigo. Ao invs de simplesmente usar o teste para verificar o nosso trabalho depois que ele estiver pronto, o TDD transforma o teste em uma atividade de projeto. Usamos os testes para clarear nossas ideias em relao a o que queremos que o cdigo faa. Conforme Kent Beck des-creveu para ns, Finalmente, consegui separar o projeto lgico do fsico. Sempre me disseram para fazer isso, mas nunca ningum tinha explicado como. Acreditamos que o esforo de escrever primeiro um teste tambm nos d uma resposta rpida sobre a qualidade de nossas ideias de projeto que tornar o cdigo acessvel para testagem muitas vezes faz com que ele seja mais claro e mais modular.

Se escrevermos testes durante todo o processo de desenvolvimento, podemos mon-tar uma rede de segurana de testes de regresso automatizados que nos d confiana para fazer alteraes.

... voc no tem nada a perder, a no ser os seus bugs

.OCONSEGUIMOSSERENFTICOSOSUFICIENTEQUANTOACOMOLIBERTADORTRABALHAREMCDIGOGUIADOPORTESTEQUETENHACUIDADOSACOBERTURADETESTE!CREDITAMOSQUEPODEMOSNOSCONCENTRARNATAREFAMOCONFIANTESDEQUEESTAMOSFAZENDOOTRABALHOCERTOEQUEDEFATOBEMDIFCILQUEBRAROSISTEMADESDEQUESIGAMOSASPRTICAS

1. Begel e Simon [Begel08] mostraram que os recm-formados na Microsoft passaram a maior parte de seu primeiro ano apenas lendo cdigo.


Resumo do Desenvolvimento Guiado por Teste

No corao de TDD, o ciclo escrever um teste; escrever algum cdigo para faz-lo funcionar; refatorar o cdigo para que seja to simples quanto uma implementao dos recursos testados. Repita.

Refatore

Torne o testebem-sucedido

Escreva umteste de

unidade falho

Figura 1.1 O ciclo bsico de TDD

medida que desenvolvemos o sistema, usamos TDD para nos dar um retorno em relao qualidade, tanto de sua implementao (Ele funciona?) quanto de design (Ele est bem estruturado?). Desenvolvendo o teste primeiro, descobrimos que nos beneficiamos duas vezes com o esforo. Escrever testes:

esclarece os critrios de aceitao para a prxima etapa de trabalho temos que nos perguntar quando sabemos que acabamos (projeto);

incentiva a escrever componentes livremente acoplados, de modo que eles possam ser facilmente testados individualmente e, em nveis mais altos, combinados (projeto);

acrescenta uma descrio executvel do que o cdigo faz (projeto); e, adiciona a uma sute completa de regresso (implementao);

enquanto que rodar testes:

detecta erros enquanto o contexto est ntido em nossa mente (implementao); e,

nos permite saber quando fizemos o bastante, desestimulando a medalha de ouro e recursos desnecessrios (projeto).

Este ciclo de reao pode ser resumido pela Regra de Ouro de TDD:

A Regra de Ouro do Desenvolvimento Guiado por Teste

.UNCAESCREVAUMANOVAFUNCIONALIDADESEMUMTESTEFALHO

O Quadro Geral 7

Refatorao. Pense localmente. Aja localmente

2EFATORARSIGNIFICAALTERARAESTRUTURAINTERNADOCORPODEUMCDIGOEXISTENTESEMMODIFICAROSEUCOMPORTAMENTO!QUESTOAPERFEIOAROCDIGOPARAQUEELETENHAUMAREPRESENTAOMELHORDOSRECURSOSQUEIMPLEMENTATORNANDOOMAISSUSTENTVEL!REFATORAOUMATCNICADISCIPLINADAEMQUEOPROGRAMADORAPLICAUMASRIEDETRANSFORMAESOUhREFATORAOvQUENOALTERAOCOMPORTAMENTODOCDIGO#ADAREFATORAOPEQUENAOSUFICIENTEPARASERFCILDEENTENDEREhSEGURAvPOREXEMPLOUMPROGRAMADORPODEEMPURRARUMBLOCODECDIGOEMUMMTODOAUXILIARPARATORNAROMTODOORIGINALMAISCURTOEMAISFCILDEENTENDER/PROGRAMADORGARANTEQUEOSISTEMAFUNCIONARDEPOISDECADAETAPADEREFATORAOMINIMIZANDOORISCODEFICARPRESOPORCAUSADEUMAALTERAOEMCDIGOGUIADOPORTESTEPODEMOSFAZERISSORODANDOOSTESTES!REFATORAOUMAhMICROTCNICAvQUEGUIADAPELABUSCAPORAPERFEIOAMENTOSEMPEQUENAESCALA$EACORDOCOMNOSSAEXPERINCIASEAPLICADARIGOROSAE CONSISTENTEMENTE AS SUASMUITO PEQUENAS ETAPAS PODEM LEVAR A APERFEIOAMENTOSESTRUTURAISSIGNIFICATIVOS!REFATORAONOUMAATIVIDADE IGUALAOreprojetoEMQUEOPROGRAMADORTOMAUMADECISOCONSCIENTEDEALTERARUMAESTRUTURAEM LARGAESCALA$ITO ISTO TENDOTOMADOUMADECISODEREPROJETARUMAEQUIPEPODEUSARTCNICASDEREFATORAOPARACHEGARAONOVOPROJETODEFORMASEGURAEINCREMENTAL6OCVERMUITODEREFATORAONOEXEMPLODA0ARTE)))/TEXTOPADROSOBREOCONCEITOODE&OWLER;&OWLER=

O Quadro Geral

tentador iniciar o processo de TDD escrevendo testes de unidade para classes no aplicativo. Isso melhor que no ter quaisquer testes e pode identificar aqueles erros bsicos de programao que todos conhecemos, mas que temos dificuldade de evitar; erros de fencepost (ou de mouro de cerca), expresses booleanas incorretas e erros afins. Porm, um projeto com apenas testes de unidade no tem os benefcios impor-tantes do processo de TDD. Vimos projetos de alta qualidade, cdigos com unidade bem testada, cuja origem era desconhecida ou que no podiam ser integrados com o restante do sistema e que tiveram que ser refeitos.

Como sabemos onde comear a escrever cdigo? E, mais importante: Como sabe-mos quando parar de escrever cdigo? A regra de ouro nos diz o que precisamos fazer: Escrever um teste que falhe.

Quando implementamos um recurso, comeamos escrevendo um teste de aceitao, o qual exercita a funcionalidade que queremos montar. Enquanto ele est falhando, um teste de aceitao demonstra que o sistema ainda no implementa tal recurso; quando ele passa, terminamos. Ao trabalhar em um recurso, usamos o teste de acei-tao dele para nos orientar quanto a, se de fato, precisamos do cdigo que estamos prestes a escrever s escrevemos cdigo que seja diretamente relevante. Subjacente ao teste de aceitao, acompanhamos o ciclo testar/ implementar / refatorar no nvel da unidade para desenvolver o recurso; o ciclo inteiro se parece com a Figura 1.2.


Refatore

Torne o testebem-sucedido

Escreva umteste de

unidade falho

Escreva umteste de

aceitao falho

Figura 1.2 Loops de retorno interno e externo em TDD

A loop de teste externo uma medida de progresso demonstrvel e a crescente sute de testes nos protege contra falhas de regresso quando mudamos o sistema. Geralmente, os testes de aceitao demoram um pouco mais, com certeza mais do que um episdio de verificao, de modo que normalmente, distinguimos entre testes de aceitao nos quais estamos trabalhando (que ainda no esto includos na mon-tagem) e testes de aceitao para os recursos que foram concludos (os quais esto includos na montagem e precisam passar sempre).

O loop interno d apoio aos programadores. Os testes de unidade nos ajudam a man-ter a qualidade do cdigo e devem passar logo depois de terem sido escritos. Os testes de unidade falhos nunca devem ser entregues ao depsito fonte.

Testagem de Ponta a Ponta

Sempre que possvel, um teste de aceitao deve treinar o sistema de ponta a ponta, sem chamar diretamente o seu cdigo interno. Um teste de ponta a ponta interage com o sistema apenas de fora; atravs de sua interface de usurio, enviando mensagens como se fossem de sistemas de terceiros, chamando os seus web services (servios web), analisando relatrios e assim por diante. Conforme discutimos no Captulo 10, todo o comportamento do sistema inclui a sua interao com o seu ambiente externo. Este geralmente o aspecto mais arriscado e difcil; ns o ignoramos por nossa conta e risco. Tentamos evitar os testes de aceitao que apenas treinam os objetos internos do sistema, a no ser que precisemos realmente nos apressar e j tenhamos um con-junto estvel de testes de ponta a ponta para dar cobertura.

A Importncia da Testagem de Ponta a Ponta: Uma histria de horror

Certa vez, Nat entrou em um projeto que usava TDD desde o seu incio. A equipe estava escrevendo testes de aceitao para captar exigncias e mostrar progresso aos representantes de seu cliente. Eles tinham escrito testes de unidade para as classes do sistema e os objetos internos eram claros e fceis de alterar. Eles estavam tendo timo progresso, e os representantes do cliente tinham aceitado todos os recursos implementados com base na passagem dos testes de aceitao.

Nveis de Testagem 9

-ASOSTESTESDEACEITAONORODARAMDEPONTAAPONTAELESEXEMPLIFICARAMOSOBJETOSINTERNOSDOSISTEMAEINVOCARAMDIRETAMENTESEUSMTODOS.AVERDADEOAPLICATIVONADAFARIAOSEUPONTODEENTRADACONTINHAAPENASUMNICOCOMENTRIO// TODO implement this

LoopsADICIONAISDERETORNOTAISCOMOSESSESNORMAISDEshow-and-tellMOSTREECONTEDEVERIAMESTARNOLUGARETERIAMDETECTADOESTEPROBLEMA

Para ns, ponta a ponta significa mais do que apenas interagir com o sistema a partir de fora isso bem poderia ser chamado de testagem de margem a margem. Preferimos ter os testes de ponta a ponta treinando o sistema e o processo pelo qual ele montado e distribudo. Uma montagem automatizada, normalmente disparada quando algum fazendo o check in do cdigo no repositrio de fontes, vai: fazer o check out da verso mais recente; compilar o cdigo e fazer o teste de unidades; inte-grar e empacotar o sistema; realizar uma distribuio, como se fosse para produo, em um ambiente realstico; e, finalmente, exercitar o sistema atravs de seus pontos de acesso externos. Isso parece muito esforo (e ), mas, de qualquer forma, precisa ser feito repetidamente durante o perodo de vida do software. Muitas das etapas podem ser trabalhosas e passveis de erro; assim, o ciclo de montagem ponta a ponta um candidato ideal para automao. No Captulo 10, voc ver o quo cedo no projeto colocamos isso para funcionar.

Um sistema distribuvel quando todos os testes de aceitao so bem-sucedidos, pois eles devem nos dar confiana suficiente de que tudo v funcionar. No entanto, ainda existe uma etapa final de distribuio produo. Em muitas organizaes, em especial, as grandes ou pesadamente regulamentadas, montar um sistema que pode ser distribudo apenas o incio do processo de lanamento. O restante, antes de os novos recursos serem finalmente disponibilizados aos usurios finais, pode envolver diversos tipos de testagem, de manipulao de operaes e grupos de dados e coordenao com os lanamentos de outras equipes. Pode haver tambm custos no-tcnicos adicionais, envolvidos com um lanamento, tais como treinamento, marketing ou um impacto sobre acordos de servio por inatividade. O resultado um ciclo de lanamento mais difcil do que gostaramos. Dessa forma, precisamos entender todo o ambiente tcnico e organizacional.

Nveis de Testagem

Montamos uma hierarquia de testes que corresponde a alguns dos loops de retorno aninhados que descrevemos anteriormente:

Aceitao: O sistema inteiro funciona?

Integrao: O nosso cdigo funciona em comparao com o cdigo que no podemos alterar?

Unidade: Os nossos objetos fazem a coisa certa; adequado trabalhar com eles?


H muitas discusses no mundo de TDD quanto terminologia, para o que chama-mos de testes de aceitao: testes funcionais, testes de cliente, testes de sistema. Pior, geralmente as nossas definies no so iguais quelas usadas pelos testadores profissionais de software. A questo importante ter clareza sobre as nossas inten-es. Usamos testes de aceitao para nos ajudar, junto com os especialistas no assunto, de modo a entender e concordar sobre o que montar em seguida. Tambm usamos os testes para garantir que no destrumos nenhum dos recursos existentes enquanto estamos criando.

A nossa implementao preferida do papel da testagem de aceitao escrever tes-tes de ponta a ponta, como acabamos de destacar, que devem ser de ponta a ponta tanto quanto possvel. Geralmente, a tendncia usar tais termos alternadamente, embora, em determinados casos, os testes de aceitao possam no ser de ponta a ponta.

Usamos o termo testes de integrao para nos referir aos testes que verificam como alguns dos nossos cdigos funcionam com cdigos usados fora da equipe, os quais no podemos mudar. Pode ser uma estrutura pblica, tal como um mapeador de persistn-cia ou uma biblioteca de outra equipe dentro da nossa organizao. A distino que os testes de integrao garantem que quaisquer abstraes que montamos em cima de cdigo de terceiros funcionem conforme esperado. Em um sistema pequeno, como o desenvolvido na Parte III, os testes de aceitao poderiam ser suficientes. No entanto, na maior parte de desenvolvimento profissional, buscam-se testes de integrao para ajudar a provocar os problemas de configurao com os pacotes externos, e para dar o retorno mais rpido do que os testes de aceitao (inevitavelmente) mais lentos.

No iremos escrever muito mais sobre tcnicas de testagem de aceitao e integra-o, visto que ambos dependem das tecnologias envolvidas e at da cultura da orga-nizao. Sero mostrados alguns exemplos na Parte III, os quais esperamos, deixaro mais clara a motivao para os testes de aceitao e mostraro como eles se ajustam no ciclo de desenvolvimento. Entretanto, as tcnicas de testagem so especficas a um estilo de programao e, portanto, comuns em todos os sistemas que assumem tal abordagem no nosso caso, so orientadas a objeto.

Qualidade Externa e Interna

Existe outra forma de ver o que os testes podem nos dizer sobre um sistema. Faz-se uma distino entre qualidade externa e interna: a qualidade externa est relacio-nada a quo bem o sistema preenche as necessidades de seus clientes e usurios ( funcional, confivel, disponvel, sensvel, etc.), e qualidade interna est relacionada a quo bem ele satisfaz as necessidades de seus desenvolvedores e administradores ( fcil de entender, de alterar, etc.). Todos podem entender o objetivo da qualidade externa: normalmente, ela faz parte do contrato para montar. A qualidade interna igualmente importante, mas, em geral, mais difcil de alcanar. A qualidade interna a que nos permite lidar com mudana contnua e imprevista, a qual, como vimos no incio deste captulo, faz parte do trabalho com software. O objetivo de manter a qualidade interna nos permitir modificar com segurana e previsibilidade o com-portamento do sistema, pois ela minimiza o risco de sermos forados a refazer um grande trabalho.

Documents

Desenvolvimento_de_Software_Orientado.pdf