Conheça o livro TDD na Prática

Olá, pessoal!  É com muita felicidade que venho compartilhar com vocês mais esse “filho”. Eu não sei nem por onde começar de fato… Bom, a seguir falo um pouco da história dele (como todo livro meu, sempre tem uma história real por trás): porquê escrevi, quem pode ler, sorteio, etc… Vou buscar ser bem breve.

Como tudo começou

Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD↳Testes automatizados4 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019TDD em Nodejs: conhecendo o JestDev (Back & Front) · mar 2019Arquitetura Hexagonal na prática com exemplos em PythonDev (Back & Front) · mai 2025Ver tudo em Dev (Back & Front) →. Até porque eu não sabia nada do assunto até inicio de 2010, apenas ouvia. Tinha tentado usar algumas vezes antes e fracassei em todas elas. Nunca entendia de fato como fazer os unit tests, muito menos escrevê-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, então, eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito!”.  Passou o tempo, tive que voltar a estudar devido a um projeto no qual trabalhei em 2010, e tinha que escrever unit tests para as coisas darem certo e então fui estudando, comecei a ler e pesquisar com mais detalhe. Lembro que o primeiro artigo que li sobre o assunto foi do Guilherme Chapiewski. Fui navegando para outros blogs, tentando entender a mecânica e praticar. Comecei a pegar o ritmo, mas confesso que naquele momento não sabia que eu fazia TDD. Era complicado, pois, pra mim, o que eu escria era um código com um framework que eu testava. Mas cada vez que programava, gostava do resultado. Então decidi me aprofundar mais no assunto e fui buscar referências “for dummy”, tanto em português, quanto em inglês. Achei? Não, pois identifiquei os seguintes problemas nas obras publicadas sobre o assunto na época:

1. Era necessário ter uma certa experiência (nem que fosse muito básica) com a mecânica de unit test;
2. Os livros eram longos e poucos práticos para iniciantes, com exemplos esquisitos que, ao término da leitura, sentia falta de algo mais concreto para praticar e dizer: ‘entendi de fato com a mão na massa’. Enfim, faltava uma direção melhor para iniciantes.

E foi quando tive a ideia de anotar tudo que fui aprendendo, tanto aquilo que deu certo quanto o que deu errado. Meses depois (no final de 2010), por “ironia” do destino, caiu no meu caminho o meu primeiro projeto, no qual usaríamos TDD. Mesmo sendo pequeno, ajudou muito. Digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Depois fui para um outro mais arrojado, de um ano, e o TDD foi a base para podermos entregar o código com qualidade, menos bug, menor custo de manutenção e respeitando os prazos. Tudo isso me fez refletir. Um dia parei, olhei para trás e perguntei: “O que aprendi até hoje? Que tal criar um livro sobre o assunto? Aliás, usar minhas anotações, experiência adquirida, para ajudar quem está querendo entrar nesse mundo?”. Observei nos fóruns e comunidades Java que muitos tinham vontade de aprender TDD, outros tinham tentado e fracassado, alguns nem sabiam por onde começar. Enfim, todos os problemas que passei eram bem recorrente para todo iniciante. E foi aí que nasceu o meu livro “TDD na Prática”. Essa é a história dele.

Quem pode ler?

Essa é uma pergunta muito comum: “será que devo comprar?”. Eu digo sempre o seguinte: compre o livro se você:

1. Conhece bem o básico do Java e de orientação a objetos. Olha o que eu estou falando: conhece bem JAVA e não JEE. Iniciantes ainda fazem confusão com as siglas do Java (não deveria, pois a primeira lição é saber as diferenças);
2. Sabe o que é unit tests ou tem ideia de para que serve;
3. Sabe a diferença entre unit test x Junit;
4. Quer de fato aprender TDD e saber que, no início, será um caminho duro, sofrido, pois não é só sentar na máquina e sair codificando. É uma forma diferente de pensar, codificar, resolver problemas, que no resultado final isso é transparente para quem olha sua aplicação e diz: “Essa eu digo 100% que foi feito com TDD, mas essa não”. A olho nu não é possível dizer isso;
5.  Gosta de desafios e quebrar a cabeça;

Como o livro está estruturado?

Bem, para quem conhece meus livros, sabe que sou bem informal na escrita e gosto de dar a sensação de que estamos mais batendo um papo do que lendo um livro. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?Bom, quando comecei a escrever, a primeira pessoa que eu pude me espelhar era eu mesmo, aquele cara que não sabia:

• nada de TDD na prática, só ouvia falar;
• conceitos de Agile↳Agile11 conteúdosO antiágil: quais as práticas que te afastam do AgileGestão Dev & TI · ago 2020Adoção de metodologias ágeis em TI pode fazer a diferença em um mundo de rápidas mudançasGestão Dev & TI · mai 2023Webinar HostGator mostra como usar Metodologias Ágeis para tirar um projeto do papelGestão Dev & TI · mai 2019Ver tudo em Gestão Dev & TI →, muito abstrato ou quase nenhum;
• tanta sigla, termos TDD, Mocks, Mockito, Junit, refactoring que na prática, juntando tudo no “liquificador”, nunca sabia se o resultado final era de fato o esperado;
• e um cara que não sabia programar usando unit test; Alias, mal entendia uma classe que tinha métodos com as anotações @Test. Me perguntava “pra que realmente isso serve? Como pode agregar valor na aplicação?”. Só ouvia as pessoas falarem: “É bom”. “Funciona”. “Usa isso que vai ser show”, ou “seus problemas acabaram, use unit test”. Mas no fundo não entendia como, e tive que aprender isso sozinho.

Então, o livro segue uma ordem que, a depender em que nível você está, pode ir lendo sequencialmente. Eu diria que se é bem iniciante mesmo, vá na ordem sequencial, mas se você já sabe mocks, usar o JUnit, etc, pode pular alguns e ir para o qual lhe interessa de imediato. Coloquei exercícios para serem feitos com o objetivo de forçar o leitor a exercitar o que aprendeu sobre TDD de formas diferentes. Vamos começando em um nível com a minha ajuda, mas depois deixo você ir sozinho, tomando suas decisões de quais testes escrever. Isso ajuda a ganhar confiança naquilo que está fazendo – o que no início com TDD todos se sentem desconfortável, inseguros e se perguntando: “será que estou fazendo a coisa certa? É isso mesmo?”. Enfim, espere exercícios um pouco diferentes do que você está acostumado a fazer no dia-dia. Também compartilho com o leitor como eu faço TDD e a gente vai vendo o que dá certo e não dá. Em alguns exercícios há respostas, para depois o leitor comparar e ver como resolvi. Não quer dizer que o seu tem que ser igual ao meu; cada um resolve de uma forma. O objetivo é que você tenha realizando os testes primeiro. Mas há outros que não temos a resposta. Fiz esses para que você possa olhar para o problema e garantir que atendeu ao requisito, ou seja, resolveu de fato usando TDD sem ter outra solução para preparar. Isso ajuda a ter mais confiança no que você entrega, já que todo “TDDista” sempre vai ouvir a seguinte frase: “Isso não funciona”, “Isso é coisa de nerd”. “Só funciona no mundo do Kent Beck e Martin Fowler”. Mas acostume-se com esses e outros comentários; faz parte do dia a dia, e o melhor de tudo: não se irrite. Há um capítulo que explico o Junit, Mocks, refactoring, falo rapidamente sobre Agile e Scrum.

Onde adquirir um exemplar?

O livro estará disponível nas melhores livrarias, Saraiva, Cultura, Fnac, etc. E nas lojas virtuais: livrosdeprogramacao.com, submarino.com.br, americanas.com.br, etc. No site da editora você também pode comprar: www.lcm.com.br.

Formato do livro

O livro será disponibilizado no formato impresso (R$ 36,80) e e-book (R$ 27,80). A versão ebook só será vendida pelo site da editora. SlideShare: Disponibilizei no slideshare alguns capítulos do livro.

Sorteio

Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.
Faça sua inscrição

Regras:

• Não é permitido realizar dois cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas um cadastro por e-mail. Lembrando que deve ser um e-mail válido, pois o contato para confirmação dos dados será feito pelo e-mail cadastrado, e o ganhador tem até 48hrs para responder, a partir da data de recebimento. Caso contrário, um novo sorteio será feito;
• O livro será enviado para o endereço informado no cadastro. Então coloque o endereço completo + ponto de referência;
• O ganhador poderá escolher se deseja a versão impressa ou e-book.

Agradecimentos

Fazer esta parte nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta, e lembrar de cada um não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que me perdoem.

Primeiro, não poderia esquecer o meu colega de trabalho Gustavo Knuppe. Apesar dele não saber que estava escrevendo este livro, foi responsável por muitas mudanças que fiz na forma de abordar o assunto de TDD, principalmente em um artigo, no qual Knuppe foi o revisor, e nesse processo sugiram várias e boas sugestões no artigo produzido que aproveitei para utilizar neste projeto. Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD, e liguei o passado com o presente, vi que ter conhecido refactoring com o Alberto fez uma diferença grande. Obrigado meu amigo! À minha namorada Ellis Ribeiro, que teve a paciência e dedicação em revisar a parte ortográfica e dar sugestões de melhoria na estrutura do livro Bom, vou ficando por aqui. Demorou, mas chegou!