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. Mas que tal pelo inicio?
Bom, a seguir falo um pouco da história dele (como todo livro meu sempre tem uma história real por trás), porque escrevi, quem pode ler, sorteio etc Vou buscar ser bem breve..
Lets go…
Agradecimentos
Fazer esta parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta: amigos, colegas de trabalho, familiares, amigo virtual, etc. 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 🙂
Como tudo começou… (Era uma vez….)
Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD, independente de que foco este teria. 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 escreve-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, daí eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito.” Dai passou o tempo, tive que voltar a estudar devido a um projeto que precisei trabalhar em 2010 e tinha que escrever unit tests para as coisas darem certo e então fui estudando, começei a ler e pesquisar com mais detalhe. Lembro que o primeiro post 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 na veia, era complicado, pra mim era código com um framework que eu testava o que escrevi. Mas cada vez que programava gostava do resultado, ficava viciado, daí 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 muuuito 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 despertou de sair anotando tudo que ia aprendendo, tanto aquilo que deu certo quanto o que deu errado também. Meses depois (no final de 2010), por “ironia” do destino caiu no meu caminho o meu primeiro projeto, o qual usariamos TDD. Mesmo sendo pequeno ajudou muito, digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Dai fui para um outro mais arrojado, de 1 ano, e 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 e olhei para tras 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 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 inicio, 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 nú não é possível dizer isso.
5. Gosta de desafios e quebrar a cabeça;
Se você se encaixa nos pontos acima, pode adquirir um exemplar, caso contrário, eu diria que não compre :).
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 ao leitor que estamos mais batendo um papo que lendo um livro em si. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?
Bom, quando começei 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”, “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 inicio 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 da certo e não da. 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 feito 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?
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.
Regras:
- – Não é permitido realizar 2 cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas 1 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.
Atualização:
O ganhador poderá escolher se deseja a versão impressa ou e-book.
Resultado
O ganhador foi: Rafael Oliveira
note: Um e-mail foi enviado para o ganhador o mesmo tem até 48hrs para confirmar o recebimento e dados de entrega. Caso não seja respondido em 48hrs a partir da data de envio, um novo sorteio será realizado.
Bom, vou ficando por aqui.
Demorou, mas chegou. 🙂
See ya!!
