rvf, software e mitos

Archive for março 2009

Não, eu não sou nenhum guru em TDD, mas aos poucos estou notando a vantagem desta técnica que agrega muito mais do que simples junits ao seu projeto. TDD te fornece na verdade outra abordagem: o desenho do seu software de uma maneira mais desacoplada e coesa.

... um pouco de história: Era uma vez um jovem desenvolvedor empolgado em introduzir técnicas de testes ágeis em sua empresa, porem, foi barrado pelo seguinte motivo: Testes (senão, os feito por testadores) são uma segunda opção (precisa dizer que a primeira é o cronograma?).  Esta é a visão dos gerentes/gestores de projetos que não conhecem TDD. A única coisa que sabem a respeito é de que TDD se testa primeiro. Na verdade, alguém que pensa assim, não sei nem como chega a este raciocínio, pois duvido muito que eles entendam o que dizem -i.e. como assim testar primeiro algo que ainda nem existe?-

TDD, não deve ser considerado como uma prática de teste -apenas-, mas sim como uma técnica poderosa de desenho/construção de aplicações OO, E, DE QUEBRA, tu ganhas o teste de unidade. Simples assim. Para cada caso, um teste que falha, onde sua história só termina quando ele passa. Por completo! A principio a idéia parece um pouco radical, mas é isso mesmo: você deve construir um teste que falhe primeiro, (nem que seja para testar se o seu JUnit está presente no seu classpath!), para, então, você ir incrementando aos poucos, refatorando, e criando as classes, métodos, xpto…  que sejam necessários para o mesmo passar e testando. Vamos brincar com  isso em um exemplo simples, de Conta Corrente:

Criamos um novo projeto, e nele, um novo teste unitário (estou utilizando o JUnit 4):

package com.wordpress.robsonvf;

import org.junit.Assert;

import org.junit.Test;

public class ContaCorrenteTest {

@Test

public void umDepositoDeveAumentarOSaldoNoValorDoDeposito() {

Assert.assertTrue(false);

}

@Test

public void umSaqueDeveDiminuirOSaldoNoValorDoSaque() {

Assert.assertTrue(false);

}

@Test(expected=RuntimeException.class)

public void umSaqueSoEhPossivelSeTemSaldo() {

}

}

Esta é a abstração mais simples possível de conta corrente que consegui chegar, creio que para o exemplo seja suficiente. Rode este teste, e veja-o falhar descaradamente e sem dó: o primeiro passo rumo a TDD foi dado. O segundo é fazer isso tudo funcionar! Notaram que, quando eu disse “abstração mais simples possível de conta corrente” ficou claro que, eu comecei a desenhar meu software antes mesmo de criar uma única classe de negócio sequer? E ainda tem gente que duvida que simples testes unitários são tão claros quanto montanhas de documentos.

Vamos trabalhar então no método: umDepositoDeveAumentarOSaldoNoValorDoDeposito, o que este método precisa para viver numa conta corrente? Na minha abstração primária, ficou assim:

@Test

public void umDepositoDeveAumentarOSaldoNoValorDoDeposito() {

ContaCorrente cc = new ContaCorrente(200d);

double saldo = cc.getSaldo();

cc.deposita(100d);

Assert.assertTrue(saldo+100d == cc.getSaldo());

}

Precisa explicar? uma nova sessão de conta corrente, um registro histórico do saldo atual com o qual a conta foi criada, um deposito, e uma verificação: o saldo esperado é igual ao saldo da conta? Você já consegue rodar este teste? Não? Está esperando o que então para criar a classe ContaCorrente e os métodos que o sua IDE chora sem parar por eles não existirem? Se utiliza o eclipse/netbeans, basta ir clicando nos erros e gerando a classe, construtores, métodos…, faltaria só implementar. Este é o seu exercício antes de continuar com a leitura.

Implementou? Rode o teste agora. Passou? Ótimo! Seu primeiro teste usando TDD foi concluído com sucesso. Se quiser, faça isso com os outros métodos até todos passarem. (recomendo fazer isso antes de ver, logo abaixo, o restante do código).

O teste pronto:

package com.wordpress.robsonvf;

import junit.framework.Assert;

import org.junit.Test;

public class ContaCorrenteTest {

@Test

public void umDepositoDeveAumentarOSaldoNoValorDoDeposito() {

ContaCorrente cc = new ContaCorrente(200d);

double saldo = cc.getSaldo();

cc.deposita(100d);

Assert.assertTrue(saldo+100d == cc.getSaldo());

}

@Test

public void umSaqueDeveDiminuirOSaldoNoValorDoSaque() {

ContaCorrente cc = new ContaCorrente();

cc.deposita(100);

cc.saque(90d);

Assert.assertTrue(10 == cc.getSaldo());

}

@Test(expected=RuntimeException.class)

public void umSaqueSoEhPossivelSeTemSaldo() {

ContaCorrente cc = new ContaCorrente();

cc.deposita(200);

cc.saque(201);

}

}

A minha classe ContaCorrente (aposto que a sua ficou igualzinha!):

package com.wordpress.robsonvf;

public class ContaCorrente {

private double saldo;

public ContaCorrente() { }

public ContaCorrente(double d) {

this.saldo +=d;

}

public double getSaldo() {

return this.saldo;

}

public void deposita(double d) {

saldo +=d;

}

public void saque(double d) {

if ((saldo-d) < 0)

throw new RuntimeException(“Saldo insuficiente!”);

saldo -= d;

}

}

Aprimore mais a lógica de negócio desta classe, envolva outras classes, e não se esqueça: primeiro o teste, depois a especificação do negócio, e por fim, a implementação… E FUNCIONANDO…

Este post foi apenas um simples estimulo para quem está querendo aprender TDD, assim como eu. Espero que você adote esta pratica para seus novos algoritmos, e, que convença seu chefe de que TDD não é apenas teste unitário avulso, mas, sim, uma nova maneira de se pensar na hora de sair construindo software.

Até a próxima.. e que venha a Agile Weekend aqui em poa 🙂

Anúncios

Depois de um tempo sem postar (puderas, semanas de finalização de versões, instalações e suporte ao teste lá no trabalho, sim, tudo isso em paralelo e não necessariamente se referem ao mesmo projeto. Já disse que começou a faculdade?), venho deixar uma lembrança aos dois ou três (obrigado mãe!) navegantes que tenho por aqui: Sabe aqueles projetinhos simples, que seu chefe tirou lá do fundo do baú, que ninguém queria fazer e você foi o felizardo em “matar no peito”? É dele que quero falar hoje.

Quando você está envolvido num novo projeto, principalmente nas vezes em que você responderá pela arquitetura do mesmo, te vem na cabeça milhares de idéias que –a principio- estão fora do escopo do mesmo (e do cliente), em conjunto com as idéias, surge uma nuvem de frameworks na sua mente, e o tesão de integrá-los, utilizando o maior numero possível de jars, preferindo a escolha de um framework de validação para o “isBlank” (créditos ao Alex) ao invés de implementar a droga do método e, de quebra, tudo isso bombando com aspectos e injeções de dependências na testa. Pense sobre isso, e reflita: Você precisa disso tudo? Você vai precisar daquela coisa que você fez apenas para “SE UM DIA…” mesmo? Não e não!

Projetos simples devem ficar simples. Quanto mais simples ele ficar, melhor pra você, pro seu cliente e para o futuro desenvolvedor que irá dar manutenção no mesmo, pois não precisará aprender aquele bolo de tecnologias que você pensou em empurrar no seu projeto. Faça uso de ferramentas que vieram para facilitar, desde frameworks para desenvolvimento rápido e ágil: Grails, Django, Rails, .. até mesmo as boas e velhas IDEs, como o NetBeans, que já gera uma aplicação JSF a partir de entidades JPA, completinha e bonitinha. Dentre várias outras opções. Keep It Simple, Stupid!

Antes de falar sobre este assunto, vamos lembrar o significado da palavra ignorância, que não necessariamente significa que o ignorante é BURRO, pois este problema se cura com a informação, mas o pior ignorante é aquele que boicota sugestões, opiniões, etc. Ao pé da letra, ignora a informação.

Estimativas de itens no processo de desenvolvimento de software, costumam ser algo que não se tem receita definida, senão a própria experiência do desenvolvedor. Metodologias ágeis introduzem algumas orientações para se fazer isso, mas ainda assim não há mágica, a métrica normalmente vem da média anterior x complexidade de cada caso –e da competência de cada um-.

Estimar bugs não faz parte do cotidiano do desenvolvedor moderno, do homem sem defeitos. O problema é que muitos esquecem que são seres humanos, e que certamente, terão que alterar casos de uso, discutir com o analista de negócios, cliente, refatorar, testar e refatorar novamente item por item, bug por bug. E, sim, imprevistos irão aparecer, e eles devem ser considerados dentro da iteração.

Mas como eu vou estimar algo que não é certo que vai aparecer? O segundo parágrafo responde novamente esta questão. O importante aqui é: Sim, você deve considerar o tempo gasto com imprevistos dentro do seu item. Nem que considerar este tempo signifique separar tempo para prever a criação de uma nova estória para um futuro conserto em uma futura iteração, mas isso valerá com base no que você espera entregar ao fim da iteração, e normalmente algo indefinido/com defeito não faz parte deste plano. Lembrem-se: estimativas andam lado a lado com o cronograma e, por motivos óbvios, a idéia do cronograma não é atrasar. Se o cronograma da vez está apto a responder por 100 horas de itens, é mais fácil incluir 4 itens de 25 horas com testes, refatorações e correções de imprevistos inclusos na estimativa, do que incluir 5 itens de 20 horas, sendo necessário atrasar o cronograma ou pior, remover um item do mesmo para entregar.

Mas, se mesmo assim, esta estimativa imprevista sobrar? Há tanta coisa que você pode fazer se ficar idle, como: testes, melhorias no código, automatizar processos, etc. Mas isso já é assunto para outro post.


Anúncios

  • Nenhum
  • Adolfo: Muito bom este post. Acho que tudo isso pode ser resumido em uma única palavra: humildade (isso não significa não defender seu ponto de vista).
  • Adolfo: Olá Robson, Alguns modelos até consegui identificar em alguns projetos que já trabalhei... Com algumas coisas eu concordo e outras não... Q
  • milah: Eu tenho um Amazon L71. Até 2 meses atrás não tive problemas com ele. Já troquei a placa de lan dele, por uma que capta melhor wi-fi. Só que ago