Mock com Mockito

Olá Pessoal,

Hoje vou apresentar o Mockito que é uma API de Mock, que tem ganhando espaço a cada dia. No post, vou falar pra que serve aos Mocks, o que evitamos e farei “reutilização da informação” sobre o que são mocks.  E para deixar tudo claro nada melhor que um exemplo feijão com arroz,  para que você possa entender como usar.  No próximo post veremos na pratica a criação de Mocks com Mockito.

Lets go…

Pra que serve o mockito?

Mockito  é uma API desenvolvida pela Google, com o objetivo de simular um objeto real para uma classe especifica. Isso pode ajudar nos testes de unidade quando precisamos verificar  a comunicação entre os objetos.

Por que usar Mock?

Usamos Mock quando temos classes que possuem dependencias, porém queremos testar apenas se uma classe está  retornando o que estamos esperando.

E o que evitamos usando mock?

Evitamos de ter que criar objetos para todas as dependencias de uma classe. Ou seja, com o mockito vamos “enganar” a execução do programa, dizendo pra ele que o objeto a ser passado é de fato o objeto que ele espera.

Na pratica

Antes de apresentar os códigos, vamos precisar pegar o conceito do “negócio” e saber como os códigos trabalham.

O cenário é o seguinte:

  • Class Cliente : um cliente ele possui alguns atributos como id, nome.
  • Classe CarroAlugado: esta classe tem como objetivo de informar/representar qual carro está alugado e para quem está alugado (cliente).  Então aqui já podemos ver que essa classe depende de um objeto da classe Cliente. Pois, um objeto da classe cliente que terá essas informações.
  • Interface AlugarCarro: temos uma interface que aluga carro, como o procedimento de alugar carro é sempre o mesmo, de ter o nome de quem está alugando  + o carro que foi alugado. Então se um cliente quiser alugar um carro terá que assinar um contrato com essa interface e informar pra ela o nome dele e o carro que deseja alugar.

E onde Mocks entram nessa história?

Mocs vão  entrar no momento que vamos simular que um cliente  c “Zezinhi” alugou um carro “Ferrari” e vamos ver se de fato  a classe tem essa reserva feita.

Os códigos a seguir:

public interface AlugaCarro {

      public void setNomeCliente(String nomeCliente);

      public void setModeloCarro(String nomeCarro);

      public String getNomeCliente();

      public String getModeloCarro();

}

Classe Cliente implementando a Interface, pois um cliente está querendo alugar um carro.

public class Cliente implements AlugaCarro {

      private String nomeCliente;

      private String modeloCarro;

      @Override

      public void setNomeCliente(String nomeCliente) {

            this.nomeCliente = nomeCliente;

      }

      @Override

      public void setModeloCarro(String nomeCarro) {

            modeloCarro = nomeCarro;

      }

      @Override

      public String getNomeCliente() {

            // TODO Auto-generated method stub

            return nomeCliente;

      }

      @Override

      public String getModeloCarro() {

            // TODO Auto-generated method stub

            return modeloCarro;

      }

}

A classe CarroAlugado  quer receber um objeto que foi instanciado contendo nome do cliente e o nome do carro alugado, e retornar esse objeto. Que nada mais é o Cliente que alugou o carro. Lembre-se o Cliente implements AlugaCarro, então temos o relacionamento HAS-A.  

public class CarroAlugado {        

      private AlugaCarro alugaCarro;

     public CarroAlugado(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }

      public AlugaCarro getAlugaCarro() {

            return alugaCarro;      }

      public void setAlugaCarro(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }    

}

Na edição 49 da revista MundoJ tem um artigo que escrevi junto com o Alexandre Gazola sobre o assunto. E lá detalhamos mais, eu sou suspeito de recomendar essa edição :).
vou ficando por aqui, espero que tenham gostado do post.

abracos, see ya!!

Overview TDD by example

olá Pessoal,

O objetivo deste post é dar um overview do livro TDD By Example, eu li o livro no inicio do ano, mas só agora conseguir liberar o post.Certamente se você quer entender algo de TDD já deve ter colocado o mesmo na sua lista. Nesse post vou dá um overview com meu ponto de visto  sobre o livro. Se houver alguma critica com certeza ela será construtiva. 🙂

Lets go…

Overview

O livro na parte I atende o que esperamos sobre TDD e o que já vimos na internet, porém o Kent Beck aborda de uma forma bem longe de qualquer linguagem de programação é abstração mesmo(e isso é bom), se você está iniciando com TDD, e se sente muito inseguro em saber qual o próximo unit tests criar, então terá dificuldades em seguir adiante em muita parte do livro, porque há questões entre linhas que só com uma boa dose de pratica que conseguimos identificar porque já fizemos. E a todo momento o Kent Beck tenta provar que TDD não é apenas escrever unit tests primeiro e sim uma forma de ti guiar para saber que está desenvolvendo algo correto conforme esperado, quando surgir um defeito, saberá fix, no menor tempo e maneira rápida e que ter tests é uma consequência. É como funciona um alarme. Se você põe um alarme na sua casa, ele não vai disparar do nada. Um alarme devidamente configurado, foi programado para disparar quando alguma regra de segurança fosse quebrada (uma porta que abriu que não deveria). E o alarme ti dar um feedback no menor tempo possível, o mesmo com os units tests, se eles quebraram é porque algo mudou em algum lugar que fez um de seus tests não ter o resultado esperado. Tirei essa conclusão durante abordagem do Beck.

E a pratica?

Não tem nada de pratico não, esqueça algo que possa fazer passo-passo, é abstração mesmo, ele põe os códigos lá e vai mostrando o que fazer. Bem, este também é o proposito do livro de mostrar o uso de TDD e não ser uma receita de bolo, porque não há receita de bolo, mas sentir que se o leitor é bem iniciante com TDD, pode vai ficar frustado. Eu diria que o publico alvo, seria um leitor que já fez alguns TDDs com aqueles software house que fazemos nas madrugadas de isonia, ou quem já usa na empresa e quer aprimorar.

As demais parte do livro é bem teoria, é abordado padrões de projeto (um breve overview), depois vai para refactoring, fala do uso de TDD, mas achei a leitura dele cansativa, o Kent Beck precisa escrever melhor na minha opnião, falo em termo de didático, sinto que na leitura fica algo “meio explicado” e que precisamos fazer associações para entender o que ele quis dizer. E não adianta dizer que bons programadores não escreve bem, a Kathy Sierra e seu time da serie “use à cabeça” provam isso para o mundo. E há outros autores por ai que sabe escrever bem, a questão é pensar mais como leitor do que autor/desenvolvedor. E isso não é uma tarefa fácil. Já consigo imaginar o sofrimento do Kent.

Custo x beneficios

O livro não é tão caro, com o dolar mais barato agora deve custar menos de 70,00 reais. Eu acho um livro válido se você já tem uma pratica de TDD e que ver alguma coisa, mas acho que há livros melhores e esperava mais do livro do Kent.

Os capitulos

Esses aqui são bem curtos, somente na parte bem teorica no final do livro que é tem caps longos, mas na de TDD na parte I, são bem pequenos mesmo de ter 3-4 páginas e achei isso legal, porque ele vai na ideia de baby-steps, explica só um trecho e explica de forma especifica.

O aprendizado

Bem, após a leitura conseguir consolidar mais um pouco de teoria de TDD, abrir mais minha mente de forma pratica que TDD guia você mais para o design e os units tests são consequência, a cobertura de code também. Fora, a organização e policiamento quando estiver no campo de batalha de TDD, não dar passos longos, saber quando preciso dar um passo atras e recomeçar, confiança no que entrego, garantir que atende aos requisitos e com alguma coisa próximo a zero de defects caso aconteça. TDD e refactoring estão mais próximos que qualquer coisa no mundo, querer usar TDD sem técnicas de refactoring é quase impossível, pois o próprio processo começa a gritar no menor tempo possível dizendo : “aqui precisa de refactoring”. Enfim, achei que foi um bom conhecimento adquirido.

Concluindo

O sentimento após a leitura é que “valeu” ter lido deu pra pegar detalhes, mas isso porque já tinha praticado e lido outros materiais antes, se tivesse lido como meu primeiro material, a frutação seria grande e teria jogado o livro de lado.

Bom fica aqui meu overview, e você o que achou do livro? Comente, please!!

Abracos, vou ficando por aqui.. see ya!! guys!

TDD:O seu primeiro TDD em Java

olá Pessoal,

Mais um post da śerie Agiile.Hoje veremos como escrever o seu primeiro TDD em Java (não é “o meu…”, pq este já fiz rs ), na semana passada eu dei um overview dos principios de TDD, nessa vamos praticar da maneira mais simples de ser. No próximo post, mostrarei como faço TDD hoje, após de algumas  “aulas” com o Kent Beck e o dia-dia fui aprimorando.Mas, não poderia de fazer um post para quem está no 0x0 do primeiro tempo :). (não sei pq,mas eu adorei a imagem que temos no inicio do post, passo horas olhando pra ela hehe)

lets go…

O foco

O foco aqui é poder compartilhar com vocês  de modo prático como foi que aprendi TDD. Pois, ainda há muitos programadores que não conseguem entender o uso, ou usar no dia-dia(claro que há exceções onde TDD não se aplica ,porém quando aplicamos este  já comprovou que os resultados são indiscutíveis).

O Exemplo

Antes de tudo vou buscar ser  bem direto ao foco do post e todo o conceito TDD será deixando de lado blz? Qualquer dúvida da uma passada no primeiro post ou no velho Google.

O nosso exemplo é o algo muito comum e escolhi ele, porque eu lembro como se fosse hoje, que  foi a partir dele que o mundo Agile marcou minha vida profissional, pois foi onde conseguir a dar meus primeiros passos ao desenvovimento guiado por testes.Sendo assim,resolvi usá-lo aqui no post. (não é nada chique, desde da faculdade, o que mais vemos é algo como RG, CPF, Locadora ,Estoque etc). Porém, o objetivo aqui não é saber se você sabe validar um RG,CPF,CNPJ, Locadora  etc. E sim se consegue desenvolver usando TDD.

Não esquecer

TDD não é apenas criar unit tests e sim ter testes inteligentes, ou seja, automatizados o suficiente para gritar quando alguém quebrar alguma regra. Outro detalhe não é pq são unit tests que você escreve de qualquer forma, é code então os principios são os mesmos utilizados no código funcional(não sei porque tem gente que separa isso, até hoje não entendi o motivo), na verdade quem desenvolve utilizando TDD tem um carinho enorme com seus testes, pois sabemos da importância deles durante o desenvolvimento e na manutenção. Já vi perguntas do tipo:

– pq não coloca tudo em um teste só? (será que precisa responder o motivo?)

– o que é um bom teste? (essa foi uma boa pergunta)

Primeiro que não há receita de bolo, mas um bom teste ele sempre tem um perfil parecido, grita de forma eficiente, ou seja, não grita por qualquer coisa que mudou, só grita quando algo que ele testa de fato mudou. Qual a diferença? Muita, há testes criados que tem varias responsabilidades e isso já passa ser um problema maior. Daí algo mudou e ele falha, mas a falha daria um novo teste especifico, mas o desenvolvedor que só escreve teste por escrever ou pq é mandatório no projeto, e importante que o teste esteja lá como métrica.

Enfim, Um bom teste deve ser especifico e rápido, assim vc pode executá-lo várias vezes.Isso é algo primário que precisamos ter em mente ao construir nossos testes.

Praticando

No exemplo a seguir temos uma aplicação que faz a “validação” de um nro de uma carteira de identidade. Este é um start-up para você ficar brincando após brincando após a leitura, mas terá que ser persistente e ir mais adiante para olhar o que tem  após omuro. Se não fizer foi ai onde quase todos desistiram.

Primeiro passo

Escrevemos a classe de teste e já fizemos o teste para os possíveis RG inválido/válido.

public class RGTest extends TestCase {

private RG validarg = new RG();

publicvoid testIsValidaRG(){

assertFalse(“retorna FALSE – inválido RG”, validarg.isValidaRG(“128641011”));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(null));

assertFalse(“retorna FALSE – RG inválido”, validarg.isValidaRG(“”));

assertTrue(“retorna TRUE – RG válido”, validarg.isValidaRG(“128640-28”));

}

Se for executado vai falhar porque não temos a classe principal “RG” que precisamos implementar. A falha anterior é de compilação, caso você execute.

public class RG {

publicboolean isValidaRG(String rg){

return false;

}

Segundo Passo

Agora precisamos testar e ver se vai falhar, pela teoria deve falhar.

O motivo da falha é que o método isValidaRG(String rg) sempre retorna false, então, nosso teste não está funcionando 100%. Pois, precisamos ter um nro de RG válido.

Terceiro passo

Fazer o teste funcionar, precisamos resolver o problema de ter um RG válido, para isso precisamos alterar o método da classe principal.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}

return true;}

Agora estamos validando, os nossos assertXXX da classe teste.

O Bug

O código abaixo passa no teste, observe que não há nenhuma regra validando letras, e sabemos não existe RG com letras. Precisamos criar um teste para isso. E resolver o bug

assertTrue(validarg.isValidaRG(“abcdefgh-ij”));

Quarto passo

criamos um método na classe RGTeste para testar se de fato nossa aplicação NÃO aceita letras, mas pelo resultado abaixo, vimos que aceita, uma vez que o método retorna TRUE, já que não há nada que proíba as letras na classe principal.

//criando um novo método para testar letras

publicvoid testIsValidaRGLetras(){

assertFalse(“retorna FALSE – inválido letras RG”, validarg.isValidaRG(“ABCDEFGH-IJ”));

assertFalse(“retorna FALSE – Inválido letras RG”, validarg.isValidaRG(“G3X8Xopa-22”));}

 Quinto passo

Precisamos agora alterar isso no código principal, para testar que letras não podem passar pelo metodo.

public boolean isValidaRG(String rg){

if((rg== null) || (rg.length()!=11)|| (rg.isEmpty()) || rg.charAt(8)!= ‘-‘){

return false;

}//fim do if

for (int i = 0; i < rg.length(); i++) {

if(i!=8){

char posicao = rg.charAt(i);

//senao for umdigitoretorne false

if(!Character.isDigit(posicao)){

return false;

}}

}return true;

}

Ambos testes passaram, assim sabemos que a validação de RG está correta, até agora. Porém, o que devemos observar que nessa mecânica, fomos escrevendo o nosso código com base nos resultados dos unit tests primeiro e não fazer o inverso. É obvio que falta muito trabalho ainda até termos um RG realmente válido e inválido, mas lembre-se que o básico de TDD é querer fazer a barra verde chegar o quanto antes com o menor esforço possível, é um tal de baby-step. É comum, queremos implementar logo a parte complexa do código, querendo fazer as validações possíveis etc. Mas, é ai que o terreno está propicio para nascer os bugs mais terríveis de nossa vida e só saberemos quando o cliente abrir. Encontrar bugs em modelo como waterfall não é uma tarefa fácil, não é a toa que o custo de manutenção nesse modelo é alto. Lembre-se que devemos desenvolver algo que qualquer outro desenvolvedor possa entender no menor tempo possível, e TDD possibilita isso, eu particularmente, quando pego um código feito com TDD olho primeiros os testes. Os testes sãos os guias que precisamos. :).

 Meu case

No exemplo do post vimos como usar TDD, quando iniciei meus estudos nunca parece vantagem (acho que você deve está com esse sentimento também), olhando apenas a execução e o resultado. Mas, confesso que só conseguir ver a essência de TDD em partes diferente do projeto, uma quando precisamos alterar algo, e manter os testes passando, ou quando recebia novos requisitos e tinha que implementar e criar mais testes, ai vi agilidade em pratica e ficando viciado, sem falar que todo time fica feliz, pelo tempo gasto na manutenção, TDD de fato dar contribuição dele na manutenção de software. Fora que com o tempo vamos vendo o quanto TDD ajuda na construção do nosso design. Daí passamos a ter um tal de design incremental.

Espero que tenham gostado do post, vou ficando por aqui, até o próximo post.

Abracos, see ya!!

Cobertura Unit Test com Eclemma

olá Pessoal,

Neste post vou falar de um plugin que temos para o Eclipse que permite saber quantos % de nossos testes de fato estão cobertos. É comum pensarmos que 100% dos nossos testes unitarios estao 100% cobertos apenas pq todos os testes passam. Quem aqui quando começou com test units não pensou nisso (eu confesso que achava isso). E neste post eu pretendo apresentar uma ferramenta que permite descobrir e dar um resultado no formato de relatório o quanto o seu code está coberto.

Lets go…

Iniciando

O plugin que vamos usar é chamado de Eclemma, ele pode ser baixado ou instalado via update no Eclipse. No site do fabricante há todas informações sobre o plugin, alguns tutoriais básicos e com imagens ilustrativas. Enfim, não tem erro para começar a usar.

Após, a instalação do plugin e o restart do Eclipse a única diferença que vc vai perceber na sua IDE é que teremos um novo botão para rodar os testes com Coverage, ou seja, “execute o testes com o plugin para eu ter relatorio da cobertura” seria algo mais ou menos assim que o botão abaixo faz.

 

Algumas Características:

  • permite exportar em html os relatorios;
  • suporte Junit 4
  • suporte ao ant, ou seja, vc pode gerar os relatórios a partir do ant
  • Baixa curva de aprendizado.

 

Antes de ir para o tópico a seguir certifique-se que já o plugin está instalado.

Praticando

Não irei abordar todos os recurso do plugin até pq nao tem tanta coisa assim, só ficar brincando um pouco com a ferramenta que alguns minutos dar para saber tudo que ela faz. Porém, para o post reservei um exemplo muito simples, onde o objetivo é mostrar como de fato a ferramenta trabalha e vai ti ajudar no aumento de cobertura dos seus testes unitarios. Criei um projeto que calcula a “Multa Mora” para alguma coisa.Isso pouco importa a questão é que essa classe recebe valores e através de um calculo financeiro terá que retorna um valor da multa a ser paga. O objetivo aqui não é ser um post para area de finanças, então deixaremos isso de lado, mas para vc saber criar bons testes precisa entender do negócio e calcular um juros simples é algo que bem do dia-dia. A seguir temos a nosso Java Project e o código da classe com seu devido calculo.

Classe MultaMora

publicclass MultaMora {

private BigDecimal taxaDia = new BigDecimal(0.33);

private BigDecimal taxaMaxima = new BigDecimal(20.00);

public MultaMora() {

// TODO Auto-generated constructor stub

}

public BigDecimal verificaAtraso(String dataVencimento, String dataPagamento,

BigDecimal valor) throws ParseException {

DateFormat df = new SimpleDateFormat(“dd/MM/yyy”);

Date dateVenc = df.parse(dataVencimento);

Date datePagto = df.parse(dataPagamento);

Calendar calendarVenci = Calendar.getInstance();

calendarVenci.setTime(dateVenc);

Calendar calendarPagto = Calendar.getInstance();

calendarPagto.setTime(datePagto);

long diferencaData = calendarPagto.getTimeInMillis()- calendarVenci.getTimeInMillis();

int umDia = 1000 * 60 * 60 * 24;

long diasDiferenca = diferencaData / umDia;

BigDecimal novoValor = calculaMulta(diasDiferenca,valor);

return novoValor;

// return diasDiferenca;

}

public BigDecimal calculaMulta(long diasAtrasado, BigDecimal valor) {

BigDecimal totalTaxa = taxaDia.multiply(new BigDecimal(diasAtrasado));

BigDecimal divisor = new BigDecimal(100);

double ttaxa = totalTaxa.doubleValue();

double ttaxamax = taxaMaxima.doubleValue();

if (ttaxa<=ttaxamax) {

return valor;

} else {

BigDecimal valorMulti= valor.multiply(taxaMaxima);

valorMulti = valorMulti.divide(divisor);

valor = valorMulti.add(valor);

return valor;

}}}

Vamos ao que interessa que é criar a classe que fará os testes e em seguida veremos quantos % de nossa classe é coberta, para isso criamos os seguites testes, o qual vai está passando.

publicclass MultaMoraTeste {

@Test

publicvoid testPeriodoValidoMes() throws ParseException {

assertEquals(new BigDecimal(120), new MultaMora().verificaAtraso(

“10/11/2010″, “20/01/2011″, new BigDecimal(100)));}

@Test

publicvoid testCalculaValor(){

//TODO

}}

Testes Passando

Vimos que os testes estão passando tranquilamente. Nada de errado, pois esperamos que eles uma hora ficasse verde. Não vamos discutir aqui o ciclo de TDD.

Agora veremos quantos % nossa aplicação está coberta pelos testes. Então precisamos rodar os testes agora usando o plugin Eclemma e para isso temos que rodar conforme a imagem a seguir:

Ao executar observe os tests units foram executados e logo em seguida temos o relatorio de cobertura.Veja que 98% não é 100% , isso é evidente, mas tem que ficar claro na sua mente que não temos 100% dos testes, e vamos navegar na arvore e ver quem não está coberto segundo a ferramenta. Mas, antes disso observe que temos quatro colunas, sendo de fácil interpretação. A primeira fala o % coberto, a segunda as instruções cobertas, a proxima instruções não cobertas e a ultima o total de instruções.Podemos ver que o método calculaMulta não está 100, mas onde não está 100%? o que está faltando? Para ver isso basta dar dois cliques em cima do método na aba Coverage, que veremos o resultado a seguir:

Observe que temos no nosso code, linhas verdes e uma vermelha, a verde significa que aquela linha está coberta pelo teste, a vermelha como sempre é um problema que precisamos resolver, ou seja, linha não está cobert. Em outras palavras não temos nenhum teste que valide aquele valor. Então vamos resolver o problema. Para isso, vamos adicionar o seguinte teste na classe de Test que criamos.

@Test

publicvoid testCalculaValor(){

BigDecimal testValor = new MultaMora().calculaMulta(1, new BigDecimal(3));

assertEquals(new BigDecimal(3),testValor);

}

Observe que agora estamos verificando aquela valor que é return ele de fato nao tinha sido testado, então criamos esse teste somente para verificar aquela parte e saber se ele vai retornar de fato o que esperamos. Rode os testes com cobertura novamente e veja agora o resultado.

Agora temos 100% de cobertura em nosso código, observe que coisa mais linda de ser vista. Porém, isso aqui foi com um exemplo muito simples com o objetivo de mostrar a vc leitor como saber quantos % de seu code está coberto. Para praticar vc pode pegar projetos antigos seus e tentar cobrir alguns cenários. Não posso deixar de falar que 100% de cobertura não significa que seu code é o melhor do mundo, o mais interessante são os testes que vc possui, sempre que for escrever seus unit tests pense, o quanto esses são eficientes. O percentual de cobertura vira consequência qto mais eficiente for seu teste.

Enfim, espero que tenham gostado do post!!
abracos,

see ya! Next post.

TDD:Minha primeira Experiência TDD


olá Pessoal,

No post de hoje é compartilhar com vocês minha primeira experiência com TDD de forma mais corporativa onde tinha que entregar algo de fato(e sair dos tests made in house).Para quem acompanha o blog, meu twitter sabe que venho estudando e se envolvendo cada dia com o mundo Agile. Como toda primeira experiência nunca sabemos como será o resultado,uma vez que não nada de background para aquele contexto. Talvez podemos falhar ou ter um sucesso do tipo “aceito”. E para sabermos disso precisamos apenas de coragem(não esqueça dessa palavra quando tiver trabalhando com TDD) e deixar o medo de errar de lado. Foi assim, que começei meus “baby-steps” com TDD. O que aprendi de cara foi: “uma coisa é usar TDD em seus projetos pessoais at home, e outro quando vamos para complexidade que temos no mundo de um negócio real, são experiências muito distante, porém se não tivesse feito aquela experiência caseira, o impacto seria maior”.

Vamos ver o que rolou…

lets go…


Cenário

Surgiu uma nova feature no projeto e teremos que implementar, e daí cai isso na minha mesa(sempre acontece isso no desenvolvimento de software certo?). O escopo, design, desenvolvimento etc. Tudo isso é responsabilidade do engenheiro/desenvolvedor/analista/arquitetos etc encontrar uma solução para a tal feature.  Alguem precisa dela done no prazo X , dentro dos criterios de aceitação YXZ.

Minha Experiência

Normalmente um produto tem  muitas features, no inicio gera uma pergunta: “Por onde começar?” “qual a melhor feature implementar por agora?” Selecionei a mais simples. Antes eu poderia ir logo na mais que aparentava difícil, mas com TDD eu precisava fazer de forma mais simples possível, desde que saisse do vermelho para verde. Daí começei a criar os units tests para uma determinada classe, pensando nos problemas, principalmente aqueles esperados, as exceções que deveriam acontecer quando o contexto fosse ZX. E foi assim que começei, da maneira mais simples e “boba”, a medida que ia adicionando novas features e o código mudando, os tests mais simples failure e isso era bom, porque sabia que uma nova feature que foi implementada, fez meu código quebrar e eu fiquei sabendo disso o quanto antes e agora devo fixar para poder ir adiante. Então esses feedbacks rapidos foram cruciais, pois não esperei até o deploy acontecer e o pessoal de QA abrir um bug 🙂

Para saber o que precisava ser feito, fiz um BillBoard, com as tasks(to-do), o que está sendo feito(in progress), e o que foi feito – Done (faltou uma coluna com blocker). Assim podemos manter o foco e saber de fato do que estamos fazendo e ajuda até dar um bom status nas scrums com o team.

O resultado

Resultado veio além do esperado, no inicio gastei bastante tempo com o units tests e seguindo os conceitos da metodologia, porém ganhei mais velocidade lá na frente e principalmente na semana final, pois tinhamos code clear(TDD ajudou identificar onde deveria refatorar), units tests fazendo boa cobertura e testes rápidos.

A moral da história que ganhei 2 dias free, pois conseguir entregar antes do deadline, com um bom tempo sobrando para fazer qualquer coisa, e o melhor de tudo a segurança que os criterios de aceitação daquela feature estava sendo alcançada com o menor esforço possível(não foi necessário dar aquelas esticadas de 2-3 hrs após o expediente). Então feature accepted, good cobertura de code e code clear. Tudo provocado por algo chamado TDD. Observem que nada disso foi planejado, era apenas entregar a feature, mas por consequência do destino, TDD trouxe vários outros beneficios de forma indireta ao desenvolvimento.

TDD não é a solução para todos os problemas que temos no desenvolvimento de software, não passa de uma metodologia que depende como está sendo aplicada ao projeto, e o mais importante pessoas etc. Se as pessoas envolvidas não estão nem ai, e não acreditam já entramos perdendo no jogo.

Eu faço uma associação bem abstrata para quem não entende TDD com aquelas metodologias que aprendemos na faculdade de como fazer o seu TCC, sabemos que só a metodologia não vai fazer o seu TCC, você vai precisar entender do assunto que deseja escrever, e começar a usar a metodologia para ti guiar como terminar aquilo da melhor forma possível e saber quando acabou ou quanto falta para acabar. E o melhor se vai dar tempo de entregar dentro do prazo (basta olhar o seu burn down chart do TCC rs).

Um livro que eu deveria ter lido, antes de ir para minha primeira experiência profissional com TDD era o do Kent Beck, mas não tive tempo, pois foi um challenge que surgiu em questão de poucos dias e daí tive que usar os materiais que já tinha em mãos e li bastante artigos, post da galera mais expert: Guilherme Silveira, Philip Calçado, Rodrigo Yoshima, Guilherme Chapiewski há alguns post e palestras legais no InfoQ. E o que não deu pra ver ler, teve que ser visto na pratica com erros e acertos.

Vou ficando por aqui, e espero que tenham gostado do post, não deixe de compartilhar como foi sua primeira experiência com TDD, ficaria feliz em ler outros cases. O objetivo do post, é mostrar para aqueles que estão na dúvida do uso de TDD, para saber de fato se funciona, tem que colocar mão na massa, o máximo que você vai descobrir no final é que TDD não atendeu aquele contexto que você tentou validar.

Abracos, see ya!!