Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD. 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.

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;

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, 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.

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.

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.

Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.

• 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.

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!