Testa esse Trem ai SÔ!!!! – Básico

Um bom programador, que se importa com a qualidade de seu software, realiza testes!

Na  MJ54, Eduardo Guerra, Editor Chefe da revista, nos leva a refletir uma questão sobre testes, ele mostra como a vida seria muito mais fácil de pudéssemos testar tudo antes de realizar algo, imagine se antes de começar um relacionamento, por exemplo, você pudesse testá-lo, e antes de assumir uma vaga de emprego, se você pudesse testar tudo, conhecer seus companheiros de programação, seu chefe, testar até os possíveis problemas enfrentados. Se isso fosse possível, a vida não seria bem mais fácil? Não teríamos muito menos erros? Bom, se isso fosse realmente possível, a pessoa que não testasse estaria dando margem para o erro, ou seja, não estaria sendo muito inteligente. Mas, e no mundo do desenvolvimento, isto é possível? Sim, é possível, e devemos utilizá-la, temos em Java, várias ferramentas que ajudam na automatização de testes, e é sobre eles e sobre suas técnicas que vamos falar neste post! Bora lá então Bixim!

Acredito que a parte mais difícil quando inicia-se a utilização de testes automatizados dentro do processo de desenvolvimento é INICIAR. Pensar nos testes, antes da implementação da lógica, ou após ela – TDD – Test Driven Development –  é o que mais me trouxe dificuldade, quando dei início ao estudo de Testes, mas posso assegurar, se você começar, não vai parar mais, na verdade você terá de se policiar para não ficar fazendo testes o dia todo.

Hoje no mercado, existem diversas ferramentas que auxiliam na criação de testes, o objetivo deste artigo é apresentar essas ferramentas, dar exemplos de utilização, e também alguns Bizus para serem usados em testes.

Uma dessas ferramentas, muito conhecidas atualmente é o JUnit, que é um framework utilizado para se realizar testes automágicos automáticos de unidade, com ele fazemos o que é conhecido como testes unitários, que nada mais é que testar as partes implementadas separadamente. Veja o exemplo:

Vamos testar uma classe simples, que faça apenas um desconto de 5% em um determinado valor. Para utilizar o JUnit vá até seu projeto, com o botão direito em cima dele clique em Build Path => Configure Build Path, depois vá ate a aba Libraries, clique em add library, selecione JUnit, depois selecione versão 4 do JUnit e finish, pronto, agora já podemos usar o JUnit.

Imagine o seguinte código:

 package br.com.blog.tdd;

public class Desconta {
	public double aplicaDesconto ( double valor ) {
		return valor -= valor* 0.05;
	}
}

Veja como é simples, ele apenas recebe um valor, e aplica o desconto de 5%, vamos agora testá-lo, para isso, vamos criar uma classe, chamada DescontaTest.

Bizu #01: Para classes de testes é convenção utilizar o nome da classe a ser testado acrescido do sufixo Test, é utilizado assim, porque o Maven sempre procura as classes *Test para poder rodá-los;

Bizu #02: As classes de testes devem sempre estar em um pacote com o mesmo nome da classe a ser testada, mas em um Source Folder diferente;

Vamos ao código de teste então, primeiro vamos fazer os seguintes imports:


import static org.junit.Assert.*; // O Assert é o vamos usar para testar
import org.junit.Test; // Anotação @Test


public class DescontaTest {

	@Test
	public void deveAplicarDesconto ( ) {
		Desconta desconta = new Desconta();

		double valorComDesconto = desconta.aplicaDesconto(100.00);

		assertEquals(95.00, valorComDesconto);
	}
}

Bizu #03: Os métodos de teste, sempre devem ser anotados com o @Test, e sempre devem ser void, ou seja, não retornam nada.

Bizu #04: Os nomes dos métodos de teste, dever dizer exatamente o que faz, por isso os métodos tendem a terem nomes grandes.

Primeiro, criamos um objeto Desconta, depois criamos uma variável, valorComDesconto, que recebe o valor atual, depois de receber um desconto de 5%, com isso criamos um assertEquals, os asserts sempre esperam um valor esperado, e o valor do retorno, ou seja, os métodos esperam dois parametros, o expected e o actuals, como em assertTrue (expected, actuals), no nosso caso, esperamos que o valorComDesconto, retorne 95.00. Com o código de teste feito, vamos rodá-lo, com o botão direito do mouse, vamos em run as, JUnit Test.

EEEEEEPAAAAAAAAAA!!!! O teste falhou!!! Deu Vermelho!!!! Mas porque? Acontece, que quando trabalhamos com um valor double, o assertEquals espera que colocamos também um delta, para ele ignorar algumas casas decimais, por isso devemos colocar assim:

 public class DescontaTest {

	@Test
	public void deveAplicarDesconto ( ) {
		Desconta desconta = new Desconta();

		double valorComDesconto = desconta.aplicaDesconto(100.00);
		assertEquals(95.00, valorComDesconto, 0.0001);
	}
}

Agora sim, rodando o código ele passa, dá Verde, ou seja, o valor que esperamos, 95.00 é o mesmo retornado no valorComDesconto.

O que queria com esse código era apenas dar uma introdução, não vou passar mais códigos neste artigo, pretendo fazer com artigo com bastante código para vocês, agora vou apresentar mais alguns Bizus, e falar bem brevemente sobre algumas outras ferramentas.

Bizu #07: Sempre Refatore seu código de Teste. Assim como no seu código, os códigos de Teste também devem ser Refatorados!

Bizu #08: Utilize o padrão builder”, para montar objetos muito complexos (Em breve falaremos de Padrões)

Bizu #09: Obedeça o Principio do menor conhecimento, Lei de Demeter. Ou seja, não faça ClasseA().MetodoA().MetodoB().MetodoC(). Obedecendo esta lei, termos menos acoplamento, e com isso melhores testes 😀

Bizu #10: Use TDD sempre que POSSÍVEL. Sempre que for possível aplique o Test Drive Development. Sempre que possível porque existem cenários que este método não é aplicado!

Espero Ter ajudado, Até a próxima!!

Fontes:

http://www.caelum.com.br/apostila-java-testes-xml-design-patterns/testes-automatizados/#3-5-junit

http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf

MundoJ 60

MundoJ 54

Anúncios

3 comentários

  1. Luiza Nunes · setembro 24, 2013

    Gostei do post!! Parabéns!
    Fiquei na dúvida em uma coisa…em que situações nós não podemos aplicar TDD?

    • Pedro Henrique de Oliveira Silva · setembro 24, 2013

      Então Luiza, primeiro obrigado pelo comentário e por ter lido o texto. Acredito que em códigos legados, já desenvolvidos, seja mais difícil aplicar o TDD, uma vez que já temos um código, então pensar no teste antes do desenvolvimento se torna “extremamente complexo”, tendo em vista que não projetado para testes. Tenho está visão hoje, pelo que estudei até agora. Obrigado mais uma vez!

  2. Luiza Nunes · setembro 25, 2013

    Sim! Faz todo sentido! Mas quando lidamos com código legado, ainda assim podemos refatorá-lo. Com certeza isso nos custa um bom tempo (para entender o que precisa ser modificado), mas é uma forma de inserir TDD em códigos legados! Sei de um caso em que colegas refatoraram um arquivo JS monstro, de mais ou menos 700 linhas. Foi triste, eles demoraram um mês para terminar, mas o resultado ficou lindo!
    Parabéns pelo post novamente!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s