© Casa do CódigoTodos os direitos reservados e protegidos pela Lei nº9.610, de 10/02/1998.Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem auto-rização prévia por escrito da editora, sejam quais forem os meios: fotográficos,eletrônicos, mecânicos, gravação ou quaisquer outros.

Casa do CódigoLivros para o programadorRua Vergueiro, 3185 - 8º andar04101-300 – Vila Mariana – São Paulo – SP – Brasil

Casa do Código

Agradecimentos

Essa talvez seja a seção mais difícil de se escrever, pois a quantidade de pessoas queparticiparam direta ou indiretamente do livro é muito grande.

Vou começar agradecimento meu pai, mãe e irmão, que a todo momento meapoiaram na decisão de fazer um mestrado, entender como ciência deve ser feita,e que sofreram junto comigo nos momentos de grande stress (que todo mestradoproporciona!).

Agradeço também aomeu orientador demestrado e doutorado, prof. Dr. MarcoAurelio Gerosa, que me ensinou como as coisas funcionam “do lado de lá”. Semele, acho que esse livro seria muito diferente; seria mais apaixonado, porém menosverdadeiro. Se meu texto olha TDD de maneira fria e imparcial, a culpa é dele.

Os srs. Paulo Silveira e Adriano Almeida também merecem uma lembrança.Mesmona época emque aCasa doCódigo não existia de fato, eles já haviam aceitadoa ideia do livro de TDD. Obrigado pela con�ança.

Todas as pessoas das últimas empresas em que atuei tambémme ajudarammuitocom as incontáveis conversas de corredor sobre o assunto. Isso com certeza enrique-ceu muito o texto.

Agradeço também aos amigos José Donizetti, Guilherme Moreira e Rafael Fer-reira, que gastaram tempo lendo o livro e me dando sugestões de como melhorar.

Por �m, obrigado a você que está lendo esse livro. Espero que ele ajude.

i

Casa do Código

Quem sou eu?

Meu nome é Mauricio Aniche, e trabalho com desenvolvimento de so�ware há porvolta de �� anos. Em boa parte desses �� anos, atuei como consultor para diferentesempresas do mercado brasileiro e internacional. Com certeza, as linguagens maisutilizadas por mim ao longo da minha carreira foram Java, C� e C.

Como sempre pulei de projeto em projeto (e, por consequência, de tecnologiaem tecnologia), nunca fui a fundo em nenhum delas. Pelo contrário, sempre foqueiem entender princípios que pudessem ser levados de uma para outra, para que no�m, o código saísse com qualidade, independente da tecnologia.

Em meu último ano da graduação, ����, comecei a ler mais sobre a ideia detestes automatizados e TDD. Achei muito interessante e útil a ideia de se escreverum programa para testar seu programa, e decidi praticar TDD, por conta própria,para entender melhor como ela funcionava.

Gostei muito do que vi. De ���� em diante, resolvi praticar, pesquisar e divulgarmelhor minhas ideias sobre o assunto. Comecei devagar, apenas blogando o queestava na minha cabeça e que gostaria de feedback de outros desenvolvedores. Maspara fazer isso de maneira mais decente, resolvi ingressar no programa de Mestradoda Universidade de São Paulo. Lá, pesquisei sobre os efeitos da prática de TDD nodesign de classes.

Ao longo desse tempo participei da grande maioria dos eventos relacionadosao assunto. Palestrei nos principais eventos de métodos ágeis do país (como AgileBrazil, Encontro Ágil), de desenvolvimento de so�ware (QCON SP e DNAD), entreoutros menores. Cheguei a participar de eventos internacionais também; fui o únicopalestrante brasileiro no Primeiro Workshop Internacional sobre TDD, em ����, nacidade de Paris. Issomostra também que tenho participado dos eventos acadêmicos.Em ����, apresentei um estudo sobre TDD noWBMA (Workshop Brasileiro de Mé-todos Ágeis), e em ����, no maior simpósio brasileiro sobre engenharia de so�ware,o SBES.

iii

Casa do Código

Atualmente trabalho pela Caelum, como consultor e instrutor. Também soualuno de doutorado pelaUniversidade de São Paulo, onde continuo a pesquisar sobrea relação dos testes de unidade e qualidade do código.

Portanto, esse é meu relacionamento com TDD. Nos últimos anos tenho olhadoele de todos os pontos de vista possíveis: de praticante, de acadêmico, de pesquisador,de apaixonado, de frio. Esse livro é o relato de tudo que aprendi nesses últimos anos.

iv

Casa do Código

Prefácio

TDD é uma das práticas de desenvolvimento de so�ware sugeridas por diversas me-todologias ágeis, como XP. A ideia é fazer com que o desenvolvedor escreva testesautomatizados de maneira constante ao longo do desenvolvimento. Mas, diferen-temente do que estamos acostumados, TDD sugere que o desenvolvedor escreva oteste antes mesmo da implementação.

Essa simples inversão no ciclo traz diversos benefícios para o projeto. Baterias detestes tendem a sermaiores, cobrindomais casos, e garantindo umamaior qualidadeexterna. Além disso, escrever testes de unidade forçará o desenvolvedor a escreverum código de maior qualidade pois, como veremos ao longo do livro, para escreverbons testes de unidade, o desenvolvedor é obrigado a fazer bom uso de orientação aobjetos.

A prática nos ajuda a escrever um so�ware melhor, com mais qualidade, e umcódigo melhor, mais fácil de ser mantido e evoluído. Esses dois pontos são impor-tantíssimos em qualquer so�ware, e TDD nos ajuda a alcançá-los. Toda prática queajuda a aumentar a qualidade do so�ware produzido deve ser estudada.

Neste livro, tentei colocar toda a experiência e tudo que aprendi ao longo des-ses últimos anos praticando e pesquisando sobre o assunto. Mostrei também o outrolado da prática, seus efeitos no design de classes, que émuito faladamas pouco discu-tida e explicada. A prática de TDD, quando bem usada, pode ser bastante produtiva.Mas, como verá ao longo do livro, os praticantes devem estar sempre alertas as dicasque o teste dará sobre nosso código. Aqui, passaremos por eles e o leitor ao �nal dolivro terá em mãos uma nova e excelente ferramenta de desenvolvimento.

A quem se destina esse livro?

Esse livro é destinado a desenvolvedores que querem aprender a escrever testesde maneira e�ciente, e que desejam aprender a como melhorar ainda mais o código

v

Casa do Código

que produzem. A primeira versão deste livro foi escrita em Java. Só que dado o su-cesso, decidi transformar os exemplos também em C�, para facilitar a vida de quemtrabalha com a plataforma .NET.

Mas, independente de sua linguagem, toda discussão feita aqui faz sentido paraoutras linguagens. Mesmo que você já pratique TDD, tenho certeza que aqui encon-trará discussões interessantes sobre como a prática dá feedback sobre problemas deacoplamento e coesão, bem como técnicas para escrever testesmelhores emais fáceisde serem mantidos.

Testadores também podem se bene�ciar deste livro, entendendo como escrevercódigos de teste de qualidade, quando ou não usar TDD, e como reportar problemasde código para os desenvolvedores.

Como devo estudar?

Ao longo do livro, trabalhamos emdiversos exemplos, muito similares aomundoreal. Todo capítulo possui sua parte prática e parte teórica. Na parte prática, muitocódigo de teste é escrito. Na parte teórica, re�etimos sobre o código que produzimosaté aquele momento, o que foi feito de bom, o que foi feito de ruim, e melhoramosde acordo.

O leitor pode refazer todos os códigos produzidos nos capítulos. Praticar TDDé essencial para que as ideias �quem naturais. Além disso, a Caelum também dispo-nibiliza um curso online sobre testes automatizados [�], que pode ser usado comocomplemento desse livro.

Boa leitura!

vi

Casa do Código Sumário

Sumário

� Introdução ��.� Era uma vez um projeto sem testes... . . . . . . . . . . . . . . . . . . . ��.� Por que devemos testar? . . . . . . . . . . . . . . . . . . . . . . . . . . ��.� Por que não testamos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��.� Testes automatizados e TDD . . . . . . . . . . . . . . . . . . . . . . . . ��.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . �

� Testes de Unidade ��.� O que é um teste de unidade? . . . . . . . . . . . . . . . . . . . . . . . ��.� Preciso mesmo escrevê-los? . . . . . . . . . . . . . . . . . . . . . . . . ��.� O Primeiro Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . ��.� Continuando a testar . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� Introdução ao Test-Driven Development ���.� O problema dos números romanos . . . . . . . . . . . . . . . . . . . . ���.� O primeiro teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Re�etindo sobre o assunto . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Quais as vantagens? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Um pouco da história de TDD . . . . . . . . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� Simplicidade e Baby Steps ���.� O Problema do Cálculo de Salário . . . . . . . . . . . . . . . . . . . . . ���.� Implementando da maneira mais simples possível . . . . . . . . . . . ��

vii

Sumário Casa do Código

�.� Passos de Bebê (ou Baby Steps) . . . . . . . . . . . . . . . . . . . . . . ���.� Usando baby steps de maneira consciente . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� TDD e Design de Classes ���.� O Problema do Carrinho de Compras . . . . . . . . . . . . . . . . . . ���.� Testes que in�uenciam no design de classes . . . . . . . . . . . . . . . ���.� Diferenças entre TDD e testes da maneira tradicional . . . . . . . . . ���.� Testes como rascunho . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� Qualidade no Código do Teste ���.� Repetição de código entre testes . . . . . . . . . . . . . . . . . . . . . . ���.� Nomenclatura dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Test Data Builders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Testes Repetidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Escrevendo boas asserções . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Testando listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Separando as Classes de Teste . . . . . . . . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� TDD e a Coesão ���.� Novamente o Problema do Cálculo de Salário . . . . . . . . . . . . . . ���.� Ouvindo o feedback dos testes . . . . . . . . . . . . . . . . . . . . . . . ���.� Testes em métodos privados? . . . . . . . . . . . . . . . . . . . . . . . . ���.� Resolvendo o Problema da Calculadora de Salário . . . . . . . . . . . ���.� O que olhar no teste em relação a coesão? . . . . . . . . . . . . . . . . ���.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ��

� TDD e o Acoplamento ���.� O Problema da Nota Fiscal . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Mock Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Dependências explícitas . . . . . . . . . . . . . . . . . . . . . . . . . . . ���.� Ouvindo o feedback dos testes . . . . . . . . . . . . . . . . . . . . . . . ���.� Classes estáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

viii

Casa do Código Sumário

�.� Resolvendo o Problema da Nota Fiscal . . . . . . . . . . . . . . . . . . ����.� Testando métodos estáticos . . . . . . . . . . . . . . . . . . . . . . . . . ����.� TDD e a constante criação de interfaces . . . . . . . . . . . . . . . . . ����.� O que olhar no teste em relação ao acoplamento? . . . . . . . . . . . . ����.�� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

� TDD e o Encapsulamento ����.� O Problema do Processador de Boleto . . . . . . . . . . . . . . . . . . ����.� Ouvindo o feedback dos testes . . . . . . . . . . . . . . . . . . . . . . . ����.� Tell, Don’t Ask e Lei de Demeter . . . . . . . . . . . . . . . . . . . . . . ����.� Resolvendo o Problema do Processador de Boletos . . . . . . . . . . . ����.� O que olhar no teste em relação ao encapsulamento? . . . . . . . . . . ����.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

�� Testes de Integração e TDD �����.� Testes de unidade, integração e sistema . . . . . . . . . . . . . . . . . . �����.� Quando não usar mocks? . . . . . . . . . . . . . . . . . . . . . . . . . . �����.� Testes em DAOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . �����.� Devo usar TDD em testes de integração? . . . . . . . . . . . . . . . . . �����.� Testes em aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . . �����.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

�� Quando não usar TDD? �����.� Quando não praticar TDD? . . . . . . . . . . . . . . . . . . . . . . . . �����.� ���� de cobertura de código? . . . . . . . . . . . . . . . . . . . . . . . �����.� Devo testar códigos simples? . . . . . . . . . . . . . . . . . . . . . . . . �����.� Erros comuns durante a prática de TDD . . . . . . . . . . . . . . . . . �����.� Como convencer seu chefe sobre TDD? . . . . . . . . . . . . . . . . . �����.� TDD em Sistemas Legados . . . . . . . . . . . . . . . . . . . . . . . . . �����.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

�� E agora? �����.� O que ler agora? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . �����.� Di�culdade no aprendizado . . . . . . . . . . . . . . . . . . . . . . . . �����.� Como interagir com outros praticantes? . . . . . . . . . . . . . . . . . �����.� Conclusão Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

ix

Sumário Casa do Código

�� Apêndice: Princípios SOLID �����.� Sintomas de Projetos de Classes em Degradação . . . . . . . . . . . . �����.� Princípios de Projeto de Classes . . . . . . . . . . . . . . . . . . . . . . �����.� Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ���

Índice Remissivo ���

Bibliogra�a ���Versão: ��.�.��

x