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!!
