rvf, software e mitos

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 🙂