Think about Tests

Apresentando FDD - Fear-Driven Development

2009-03-30T01:00:00.000-07:00

Hoje lendo o blog do Nerdson (muito bacana), vi um negócio engraçado e que se tornou mais engraçado pelo fato de conhecer um caso real que usou esta técnica.

Numa empresa que trabalhei anteriormente, tinha um brother recém-promovido à programador (Ou anapropégua* como preferir). Acontece que este carinha tinha um gerente super-star, que se parecia muito com o Dragãozinho do Nerdson.

O pobre infeliz (do programador), estava com a corda no pescoço, com uns 3 projetos em atraso e 1 que tinha que terminar naquele mesmo dia, desta forma, 18:30 hs na mesa do programador estavam: O próprio, O "coordenador" dele, e o Gerente Super-Star.

O pobre programador chegou a um momento de quase um AVC e choramingou: "Vou la fora dar uma respirada, e volto logo". O gerente então lasca: "Sente aí e quando você terminar, pode respirar!".

Veja o Post do Nerdson para ter uma ilustração desta técnica incrível.

*anapropégua = ANAlista, PROgramador e fí duma ÉGUA.

Reparando uma injustiça com a Integração Automatizada.

2009-03-20T03:58:00.000-07:00

A algum tempo atrás crucifiquei o Sr. Cruise Control, na verdade não a ferramenta, mas o fato de automatizar esta integração. Porém, esses dias vi um novo cenário (que eu não tinha pensado) e que a automatização da Integração pode ser um GRANDE aliado.

Imagine você que seu desenvolvimento esteja tão, ou simplesmente, evoluído o bastante para termos várias "formas" de testes automatizados. Imagine que um de seus testes seja algo como, apagar TODA uma base de dados, e popula-la novamente com os dados mais atuais da aplicação, e só depois executar uma bateria de testes automatizados.

O bom e velho Build de 10 minutos vai pra roça !!!

Considere o exemplo acima apenas um EXEMPLO, pois podem existir várias situações em que sua integração ultrapasse, em muito, o tempo de 10 minutos.

Resumindo, você deve ter "2 momentos" de integração:

* A integração local: que seria a integração realizada em sua maquina, fazendo os testes unitários e, possivelmente, testes de integração;
* E o momento da integração automatizada, que conta com todas as vantagens da ferramenta, como relatórios e afins.

Um primeiro Teste Unitário em Ruby

2008-10-17T07:04:00.000-07:00

http://thinkinrails.wordpress.com/2008/10/17/um-primeiro-teste-em-ruby/

Novas atividades

2008-09-13T18:40:00.000-07:00

Moçada,

sei que estou meio ausente, e voltar a ativa com um post que não tem nada haver com o blog é desastroso, mas tenho um bom motivo:

A mais de 2 meses venho estudando Ruby on Rails, direcionei todas as minhas atenções e horarios vagos para isso e estou percebendo que devo dedicar mais tempo ainda. Bem, o caso é que criei um novo blog pra falar sobre Ruby on Rails, e venho convidar a todos que se interessem pelo assunto a visita-lo. Bem, os assuntos que se relacionem com testes eu postarei nos 2 blogs, então se não se interessar por Rails, pode aguardar os posts sobre testes aqui mesmo.

Até mais

Fóruns que precisamos conhecer (Sobre Testes)

2008-06-05T07:20:00.000-07:00

Em desenvolvimento, dúvidas são frequentes, por isso vou listar alguns lugares (Fóruns sobre teste e utilitários) que podemos encontrar soluções para os mais diversos problemas e mesmo encontrar respostas para nossas novas dúvidas.

EclEMMA: https://sourceforge.net/forum/forum.php?forum_id=614869
EMMA: http://sourceforge.net/forum/forum.php?forum_id=373865
JMock: http://www.jmock.org/mailing-lists.html
JMockit: https://jmockit.dev.java.net/servlets/SummarizeList?listName=users
JUnit: http://www.nabble.com/JUnit-f2687.html
Selenium: http://www.nabble.com/Selenium-f14083.html

XP-Rio (Sobre práticas ágeis, TDD, outras formas de testar software): http://tech.groups.yahoo.com/group/xprio/

Resolvendo o problema do finally no EclEMMA

2008-06-05T06:26:00.000-07:00

A algum tempo reclamei do meu colega EclEMMA aqui, acontece que fiz uma pergunta num forum do produto, e mesmo com o meu inglês digno de um índio, obtive uma boa resposta:

"Hi, the yellow line is an artifact of the underlying coverage technology which is based on byte code instrumentation. "Finally" statements only exist in Java source code, the Java compiler creates corresponding control structured in byte code. The finally block is actually executed in two different cases: In case of normal execution and in case of an exception within the try block. You're test code follows only one the these paths, therefor the line is marked yellow (partial execution)."

Muito bacana, dessa forma percebi que tenho que deixar o método disparar a exceção, caso ela aconteça, e tenho que verifica-la no método de teste.

Usando o mesmo exemplo, eis a forma correta de testar e obter o resultado correto com o EclEMMA :

1: public class StupidClass {
2:
3:  public String falar() throws Exception{
4:
5:   try
6:   {
7:    System.out.println("try: ");
8:    System.out.println("oyeah!");
9:   }
10:   catch (Exception e)
11:   {
12:    System.out.println("catch");
13:    e.printStackTrace();
14:    throw e;
15:   }
16:   finally
17:   {
18:    System.out.println("ogou!");
19:   }
20:
21:   return "oh! fezes";
22:  }
23: }

e seu teste fica assim:

0: import static org.junit.Assert.assertEquals;
1: import static org.junit.Assert.assertNotNull;
2:
3: import org.junit.Before;
4: import org.junit.Test;
5:
6: public class TestStupidClass {
7:
8:  StupidClass stupidClass = null;
9:
10:  @Before
11:  public void antes(){
12:   stupidClass = new StupidClass();
13:  }
14:
15:  @Test
16:  public void falarTest() throws Exception{
17:
18:   assertEquals("Test 1", stupidClass.falar(), "oh! fezes");
19:
20:   Exception exp = null;
21:
22:   try{
23:    stupidClass.falar();
24:   }catch (Exception e) {
25:    exp = e;
26:   }
27:
28:   assertNotNull("Test 2", exp);
29:
30:  }
31: }

Obrigado ao pessoal do EclEMMA.

O que o cliente quer, o que você entrega

2008-05-13T09:15:00.000-07:00

Essa figura é bem manjada, mas ilustra muito bem o que acontece com o desenvolvimento de software. As metodologias ágeis vieram ao mundo pra tentar reduzir essa distancia entre o que o "cliente quer" e o que você entrega, algumas práticas como Interações Curtas e Testes podem te ajudar a estar sempre mais próximo de atingir os seus objetivos.

Teste de Recuperação

2008-05-12T09:40:00.000-07:00

Depois de um email que me foi enviado pela Roberta Laquini, questionando alguns assuntos, procurei saber um pouco sobre Testes de Recuperação, bem, nunca ouvi falar e depois que vi uma fonte sobre o assunto percebi porque isso não é muito comum:

"Avalia o comportamento do sistema após ocorrência de erro, sobrecarga ou condições anormais, como queda de luz e rede. Nestes testes são tipicamente simulados cenários inesperados da mesma forma que ocorrem nos ambientes reais, como a remoção forçada de um cabo de rede, o desligamento repentino da energia, etc."

Imagina aí um cara desenvolvendo e indo debaixo da mesa puxar o cabo de força, mas é isso mesmo. :)

JMockit - RealMethodNotFoundForMockException

2008-05-07T06:58:00.000-07:00

Existe um erro bem comum quando usamos JMockit: "Corresponding real methods not found for the following mocks".

Por um erro, meu, de tradução, imaginava que esse erro devia-se a um método da classe real não estar sendo criado na minha classe Mock, quando li com calma hoje pela manhã, percebi que é o contrário, um método implementado na minha classe Mock não existe na classe real.

Esse erro é comum de acontecer quando usamos uma classe de terceiro, normalmente empacotada num jar. No meu caso, tentava mockar a classe WebApplicationContextUtils do Spring e tive que procurar o código fonte no google pra saber a assinatura do método.

Percebi também que se você não criar o método falso para um método da classe real, ele vai invocar o método da classe real.

Problema com o CGLIB

2008-05-07T05:26:00.000-07:00

O CGLIB foi descoberto quando procurávamos mockar classe concretas , ele é muito útil em muitas situações, principalmente quando usamos classes de outros. Acontece que esta semana descobrimos um probleminha nele: A classe que será mockada precisa do construtor default.

O interessante é que ele executa o construtor default quando o método mock(Class) é invocado. Isso pode ser um problema, no meu caso, a classe é de terceiro e não tem o construtor default, mas acredito que o CGLIB vai continuar sendo a alternativa pra esse tipo de situação.

Send us code. Get back tests. Free.

2008-05-05T12:54:00.000-07:00

Dica de pesquisa.

O Igo deu uma dica de pesquisa bem interessante, como passei o dia tendo problemas com a rede e não consegui testar, envio a dica pra, caso alguém queira e tenha tempo, testar esse cara.

JUnitFactory promete gerar os testes para o seu código legado, com uma API de Mock Objects diferente das mais populares de mercado, pode ser uma boa alternativa pra quem tem interesse em gerar grande quantidade de testes para código já existente.

Aqui uma demonstração de como usar o JUnitFactory.

EclEMMA e seus problemas com o finally

2008-04-24T14:01:00.000-07:00

Hoje tive a maior decepção do ano, logo com o EclEMMA, um plugin que tinha como extremamente confiável.

Para ilustrar o problema vou fazer um exemplo bem simples (desculpem os termos usados, mas estou meio irritado com isso):

0:
1: public class StupidClass {
2:
3:  public String falar(){
4:
5:   try
6:   {
7:    System.out.println("oyeah!");
8:   }
9:   finally
10:   {
11:    System.out.println("ogou!");
12:   }
13:
14:   return "oh! fezes";
15:  }
16:
17: }

E seu teste:

0: import static org.junit.Assert.assertEquals;
1:
2: import org.junit.Before;
3: import org.junit.Test;
4:
5: public class TestStupidClass {
6:
7:  StupidClass stupidClass = null;
8:
9:  @Before
10:  public void antes(){
11:   stupidClass = new StupidClass();
12:  }
13:
14:  @Test
15:  public void blablabla(){
16:   assertEquals(stupidClass.falar(), "oh! fezes");
17:  }
18:
19: }

Para a minha infeliz surpresa, o corpo do finally não é considerado coberto, na verdade ele é "amarelado".
Pra quem não sabe o que significa o amarelo ou verde ou vermelho, veja aqui.

Agora é buscar outra ferramenta que atenda essa necessidade, quando, e se, achar, posto aqui.

Acessando um método não visível "na marra"

2008-04-17T12:25:00.000-07:00

Um dia eu falei que um método privado deveria ser testado por intermédio de outro, já que se não existir um método que o chame, ele nem deve existir. Bem, hoje vi que não é verdade, ou pelo menos encontrei um caso que precisava implementar um método protected em uma classe que seria enviada como parâmetro para outro método.

Aí pensei, "tá na hora de sujar as mãos".

Como é possível que nem todos saibam usar Reflection, vou postar aqui o código para ajudar a quem precisar:

Este é o método:

protected PasswordAuthentication getPasswordAuthentication()
{
return new PasswordAuthentication(mailSender.getUsername(), mailSender.getPassword());
}

e assim o acesso:

public void testGetPasswordAuthentication() throws Exception{
Method metodo = authenticatorImpl.getClass().getDeclaredMethod( "getPasswordAuthentication", new Class[]{});
metodo.setAccessible(true);
metodo.invoke(authenticatorImpl, new Object[]{});
}

Boas práticas - Parte II

2008-04-17T05:44:00.000-07:00

Uma boa prática que tenho percebido ajudar muito na análise de testes, é o uso do parâmetro (message) do tipo String que todos os asserts do JUnit suportam.
Desta forma indico que sempre este parâmetro seja utilizado.

Exemplos:
assertEquals("Test 1", true, true);
assertTrue("Test 2", false);
assertNotNull("Test 3", new Object());

e todos os outros asserts se comportam da mesma forma.

O erro aparecerá assim: junit.framework.AssertionFailedError: Test 2
Indicando onde o erro aconteceu.

Numa classe de testes onde você tenha muitos assert é quase impossível, ou no mínimo complicado, encontrar em que assert o teste falhou.

BDD - Mais uma técnica de programação?

2008-04-02T08:51:00.000-07:00

Behaviour Driven Development é algo que, atualmente, se ouve bastante no meio Ágil, e lendo um artigo do Ivan Sanchez sobre o assunto, vejo que não existem diferenças "em termos de técnica de programação" entre BDD e TDD (Test Driven Development), aparentemente o BDD foi criado para substituir conceitualmente o TDD, pois o termo Test pode ser (e é) facilmente confundindo com Validação e causa uma certa distância entre nós e os humanos normais (não-desenvolvedores).

Segundo o Portal do BDD, esta técnica é a evolução "lógica" do TDD e do Acceptance Test Driven Planning. BDD têm um vocabulário que pode ser utilizado por todos os interessados: empresa, desenvolvedores, testadores, analistas e gerentes. Este vocabulário é tido como o "grande bum" do BDD.

BDD é mais rico que TDD quando pensamos em ferramentas, pois existe um conjunto de frameworks que auxilia na sua implementação, para Java o mais famoso (e o único que eu conheço) é o JBehave.

Vejo BDD como uma idéia bem bacana e que merece ser experimentada, os depoimentos que escuto são sempre positivos.

Desacoplando para melhorar o design e facilitar os testes

2008-04-02T08:26:00.000-07:00

Usando TDD, normalmente nos deparamos com situações em que precisamos mudar nossa implementação para atender a algum teste, isso é normal e viável, já que os testes são parte do sistema.

Quando o Paulo Silveira veio a Fortaleza e ministrou um workshop sobre Java, falou-se muito sobre desacoplar, não usar métodos estáticos (sempre que possível) e outras boas práticas como IoC, acontece que venho buscando sempre soluções pra esses casos sem mudar minha implementação, na maioria até consegui, lógico que com maior dificuldade e esforço.

Assim, esta semana discutimos a implementação de alguns testes que estavam muito complicados e ví que o que o Paulo havia falado era bem simples, ao menos da maneira que solucionamos o problema. Vou ilustrar com um exemplo bem simples pra deixar claro como podemos facilitar os testes desacoplando algumas coisas.

Primeiro quero dizer que com um Spring da vida você não vai precisar usar esse artifício, pois com o IoC do Spring você pode fazer isso;
Segundo, é importante ficar atento, porque se existirem muitas dependência, um artifício simples como esse pode não funcionar.

Ao exemplo:

Tenho 3 classes.

0: public class ClasseA {
1:     public void metodo1(){
2:         ClasseB classeB = new ClasseB();
3:         classeB.metodo2();
4:     }
5: }

0: public class ClasseB {
1:     public void metodo2(){
2:         System.out.println(ClasseUtil.m1());
3:
4:         ClasseUtil classeUtil = new ClasseUtil();
5:         System.out.println(classeUtil.m2());
6:     }
7: }

0: public class ClasseUtil {
1:  public static String m1(){
2:   return "m1";
3:  }
4:
5:  public String m2(){
6:   return "m2";
7:  }
8: }

No teste da ClassseB terei algumas dificuldades porque existe uma chamada a um método estático (podemos usar JMockit, porém, dependendo do retorno, torna-se uma tarefa muito complicada) e um instanciamento da ClasseUtil.

Como poderíamos evitar isso? Bem simples:

Passaremos a instância da ClasseUtil como parâmetro do método:

0: public class ClasseA {
1:  public void metodo1(){
2:   ClasseB classeB = new ClasseB();
3:   classeB.metodo2(new ClasseUtil());
4:  }
5: }

0: public class ClasseB {
1:  public void metodo2(ClasseUtil classeUtil){
2:   System.out.println(classeUtil.m1());
3:   System.out.println(classeUtil.m2());
4:  }
5: }

O design fica bem simples e os testes mais fáceis de implementar.

Devo mockar métodos de classes "utilitárias"?

2008-03-17T04:50:00.000-07:00

Se considerarmos que esses métodos estão fora do escopo testado ou que serão testados isoladamente, a resposta é não, porém, pensando com cuidado, percebo que esses métodos normalmente são recheados de Reflections e Generics para serem o mais genérico possível, e pensando em algumas situações acho que podemos mudar de opinião.

Temos aqui na empresa uma classe CollectionUtil onde criamos métodos para manipular Collections. Nesta classe criamos um método não tão genérico quanto o possível, porém, o suficiente para a nossa utilização, sendo que me deparei com uma coisa:

O método é responsável por receber uma Collection e retornar um Array de ids (todas as nossas entidades tem esse atributo):

 0: public Long[] convertCollectionToArrayIds(
1:   Collection coll)
2: {
3:  Method mKey = null;
4:  Long[] ids = new Long[coll.size()];
5:
6:  try
7:  {
8:   int count = 0;
9:   for(T clazz: coll)
10:   {
11:    mKey   = clazz.getClass().
12:     getMethod("getId");
13:    ids[count] = (Long) mKey.invoke(
14:      clazz,new Object[]{});
15:    count++;
16:   }
17:
18:   return ids;
19:  }
20:  catch(Exception e)
21:  {
22:   e.printStackTrace();
23:   return null;
24:  }
25: }

Imagine uma situação onde alguém, não importa o porque, não use o atributo "id" e sim "cod" ou um erro de digitação e sai um "ide", ou qualquer outra coisa, pensando nisso, vejo que a melhor saída é: Não mockar o método "utilitário".

Use o bom senso, um método utilitário que envie um email ou que não seja tão genérico assim, pode ser mockado. Outra alternativa é enriquecer o método "utilitário", fazendo verificações se a entidade possui o atributo "id".

Mais sobre Cobertura de Código (Code Coverage)

2008-03-11T04:44:00.000-07:00

Mais uma vez caí numa discussão sobre garantir ou não 100% de cobertura, na ultima vez que discuti o assunto caí num ponto onde 100% de Cobertura só serve para o marketing da minha empresa, ou setor ou de um produto, de qualquer forma, somente para Propaganda. Acontece que algumas coisas foram mudando minha opinião, e achei que deveria atualizar a opinião do Blog também.

* Sem garantir os 100% de Cobertura, fica complicado verificar se o que deve ser testado, foi testado. O responsável, ou toda a equipe tem que ficar constantemente verificando a cobertura de uma determinada classe ou de um determinado pacote;
* Alterações em um método que não deveria ser testado fazem com que ele precise de teses. Num "getzinho" simples que só retorna uma data, você pode incluir um regra que: se não houver data no objeto, retorne a data de hoje. Se o desenvolvedor esquecer de fazer o teste, dificilmente alguém vai perceber a ausência dele;
* Num momento de refactoring, a confiança nos testes fica abalada. Se você não sabe se todo o sistema esta coberto, como você vai garantir que suas alterações não quebraram o código? Resposta fácil, procurando a classe de testes responsável pelo método que esta sendo refatorado e verificando se existe algum teste para aquele método específico.

Quando pensamos em todos esses pontos, e percebemos outros como o que vi no Blog do Wagner Elias, ótimo texto por sinal, percebemos que garantir a cobertura de código é muito válido, não somente a nível de Propaganda.

Uma alternativa muito boa é automatizar alguns testes, ou gerar o código das situações mais genéricas, prefira sempre a primeira situação, manter código desnecessário é um custo muito alto. Sendo assim, um get ou set estaria sendo coberto por esse teste genérico, até ter sua implementação alterada, neste caso um teste "de verdade" seria criado para ele.

Para ver os outros post sobre o assunto.

Método mockado retornando uma Exception

2008-03-06T10:19:00.000-08:00

Recentemente precisei fazer um teste em um método e que deveria verificar o comportamento do mesmo quando um método invocado por ele retornasse uma Exception específica.

Exemplo do método:

0: public String delete() throws Exception
1: {
2:  try
3:  {
4:   vendaManager.delete(venda.getId());
5:  }
6:  catch (UnexpectedRollbackException e)
7:  {
8:   addActionError("Não foi possível cancelar venda.");
9:   return Action.INPUT;
10:  }
11:  return Action.SUCCESS;
12: }

No expect do método é só retornar a exception da seguinte forma:

0: vendaManager.expects(once()).method("delete")
1:  .with(ANYTHING).will(throwException(
2:    new UnexpectedRollbackException("")));
3: assertEquals(action.delete(), "input");

Descobrindo o Selenium

2008-02-28T12:58:00.000-08:00

Selenium é a ferramenta mais utilizada para Testes de Integração, ou ao menos a mais popular no meio Java.

Para os nossos exemplos, vamos usar o plugin para o FireFox que facilita muito a tarefa (Uma lista de links importantes esta no final do post, incluindo downloads de plugins e ferramentas).

O Selenium tem o seu próprio testRunner, porém nós vamos utilizar o Selenium-RC para testarmos via código Java, isso possibilita integrar os testes de Selenium com seus Testes Unitários.

Com o plugin do FireFox, iniciamos a usar o Selenium:

Começamos a gravar o processo que queremos testar, no caso um simples login:

Quando completamos o processo que queremos testar, paramos a gravação:

Exportamos o teste feito para código Java:

O código gerado é esse:


0: import com.thoughtworks.selenium.*;
1: import java.util.regex.Pattern;
2:
3: public class login extends SeleneseTestCase {
4:  public void testLogin() throws Exception {
5:   selenium.open("/login.action;" +
6:     "jsessionid=21FC72563" +
7:     "78F1D482601E23C929635A1");
8:   selenium.type("j_password", "1234");
9:   selenium.click("submit");
10:   selenium.waitForPageToLoad("30000");
11:   assertEquals("Área Inacessível",
12:   selenium.getAlert());
13:  }
14: }

O objeto selenium no método acima, nos da informações da página, como um alert, tempo esperado para a página carregar, o titulo, dentre outras coisas.

Para que o teste fique completo, estendemos TestCase, declaramos um atributo selenium do tipo Selenium e criamos o setUp e tearDown:


0: public void setUp() throws Exception {
1:  String url =
2:   "http://www.meuslivroseletronicos.com.br";
3:  selenium = new DefaultSelenium("localhost",
4:    SeleniumServer.getDefaultPort(),
5:    "*firefox", url);
6:  selenium.start();
7: }
8:
9: protected void tearDown() throws Exception {
10:  selenium.stop();
11: }

A classe finalmente deve ficar assim:


0: import junit.framework.TestCase;
1: import org.openqa.selenium.server.SeleniumServer;
2: import com.thoughtworks.selenium.DefaultSelenium;
3: import com.thoughtworks.selenium.Selenium;
4:
5: public class login extends TestCase {
6:  private Selenium selenium;
7:  public void setUp() throws Exception {
8:   String url = "http://www.meuslivroseletronicos" +
9:   ".com.br";
10:   selenium = new DefaultSelenium("localhost",
11:     SeleniumServer.getDefaultPort(), "*firefox",
12:     url);
13:   selenium.start();
14:  }
15:
16:  protected void tearDown() throws Exception {
17:   selenium.stop();
18:  }
19:
20:  public void testLoginLivro() throws Exception {
21:   selenium.open("/login.action;jsessionid=BEF" +
22:   "47FEE6B27A5E7EA20DB20E6F3F4F2");
23:   selenium.type("j_username", "admin");
24:   selenium.type("j_password", "1234");
25:   selenium.click("submit");
26:   selenium.waitForPageToLoad("30000");
27:   assertEquals("Livro Eletronico",
28:     selenium.getTitle());
29:  }
30: }

Estarte o selenium server: java -jar selenium-server.jar que está no diretório selenium-remote-control-0.9.2\selenium-server-0.9.2 do Selenium-RC.

Agora rode como se fosse um teste comum do JUnit.

Links que podem ajudar:

Selenium (http://selenium-ide.openqa.org/)
Download em (http://selenium-core.openqa.org/download.jsp)

Selenium IDE 4 Firefox (http://release.openqa.org/selenium-ide/0.8.7/selenium-ide-0.8.7.xpi)

Selenium 4 Java (http://selenium-rc.openqa.org/java.html)
Download em (http://selenium-rc.openqa.org/download.jsp)

Teste de Integração

2008-02-25T13:12:00.000-08:00

O Teste de Integração, ao contrario do Teste Unitário, não se preocupa com o conceito de módulos. Essa modalidade de testes, como seu nome indica, promove o teste de uma funcionalidade sem se preocupar com "de quem é a responsabilidade?".

Pense numa situação de um cadastro, com Teste Unitário você deve criar um teste para as regras de negócios, um outro para os métodos de persistência, porém, no Teste de Integração, você testa somente o método Inserir, ou Update ou Delete e deixa que os módulos si relacionem de verdade, sem Mock Objects, sem nenhum artifício qualquer.

Quando falo "comparando" Testes Unitários com Testes de Integração, não estou dizendo que um é melhor que o outro, até porque eles devem conviver de maneira harmônica, os Testes de Integração verificam um outro escopo, verificam a integração entre os módulos, tanto que, se os testes unitários foram feitos de maneira correta, um teste de integração NUNCA (ao menos, não deverá) encontrará um problema na regra do método implementado, pode encontrar problemas numa injeção de dependências feita pelo Spring ou coisa parecida.

Breve vou escrever sobre o Selenium, uma ferramenta espetacular para fazer Testes de Integração.

Melhorando o Design da Aplicação e a construção de testes

2008-02-18T13:23:00.000-08:00

O TDD tem como sua maior incumbência, auxiliar na construção do design dos seus métodos, com o tempo vimos situações particulares e tentamos encontrar soluções para as mais diversas situações, como JMockit, CGLib e outros.

Porém tivemos, aqui na empresa, a visita do Paulo Silveira da CAELUM e mudou bastante o meu conceito de como alcançar a melhoria no desenvolvimento de testes e consequentemente, das classes de um sistema.

Citarei umas idéias que achei bem interessantes:

1) Use Injeção de Dependência. No Spring temos o IoC que nos proporciona essa técnica, é notório a facilidade que ganhamos na construção de testes, principalmente no TDD.
2) Use e abuse de Interfaces. O uso de Interfaces nos oferece, além do óbvio, uma facilidade muito maior na construção de testes, pois o padrão para construção de Mock Objects é utilizar Interfaces.
3) Evite os método estáticos. Métodos estáticos tem alto acoplamento e são ruins de testar, neste momento eu falei sobre JMockit, mas ele frisou que testes devem ser simples e que artifícios como esses podem complicá-los.

Por fim, ele falou algo que achei bem interessante, acho que ele tirou do Design Patters do GoF:

"Evite as extenções e abuse das implementações", não sei bem se foram essas as palavras, mas a idéia foi essa.

E como me lembrou o Capitão Sávio Pierre, "Em vez de extender, procure fazer Agregações ou Composições". Isso também é sensacional.

Bem, acho que existem situações em que essas boas práticas podem não ser possíveis, mas confesso que estarei sempre atento a elas.

Fica aqui a indicação da CAELUM e do próprio Paulo Silveira, o workshop ministrado por ele foi muito bacana.

Fazendo testes com Ant + JUnit + JMockit

2008-02-11T12:52:00.000-08:00

Para fazer seus testes com o auxílio do Ant, seguem alguns passos que extraí do que já utilizamos aqui na empresa:

Primeiro Passo: crie 2 arquivos e coloque na raiz da aplicação:

build.xml
build.properties

Segundo Passo: no build.xml, crie a seguinte estrutura (ela pode ser mais simplificada):

*tire os '$' de todas as linhas
<$project name="NomeDoProjeto" basedir=".." default="integrate">
<$property file="${ant.project.name}/build.properties"/>
<$property name="project.dir" value="${ant.project.name}"/>
<$property name="src.dir" value="${project.dir}/src"/>
<$property name="build.dir" value="${project.dir}/web/WEB-INF/classes"/>
<$property name="lib.dir" value="${project.dir}/web/WEB-INF/lib"/>
<$property name="allTests.class" value="com.NomeDoProjeto.test.AllTests"/>

<$path id="project.classpath">
<$pathelement location="${build.dir}"/>
<$fileset dir="${lib.dir}">
<$include name="*.jar"/>
<$/fileset>
<$fileset dir="${tomcat.lib}">
<$include name="*-api.jar"/>
<$include name="jasper-runtime.jar"/>
<$/fileset>
<$/path>

<$taskdef name="junit" classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
<$classpath refid="project.classpath"/>
<$/taskdef>

<$target name="build">
<$mkdir dir="${build.dir}"/>
<$javac debug="on" srcdir="${src.dir}" destdir="${build.dir}" failonerror="true">
<$classpath refid="project.classpath"/>
<$/javac>
<$/target>

<$target name="test" depends="build">
<$dirname file="build.xml" property="current.dir"/>
<$junit haltonfailure="true" haltonerror="true" fork="true" dir="${current.dir}">
<$jvmarg value="-javaagent:${jmockit.dir}"/>
<$classpath>
<$path refid="project.classpath"/>
<$/classpath>
<$formatter type="plain" usefile="false"/>
<$test name="${allTests.class}"/>
<$/junit>
<$/target>

<$/project>

Terceiro Passo: no build.properties, crie as variáveis( ${variavel} ) que são usadas no xml:

tomcat.lib=C:\\Arquivos de programas\\Apache Software Foundation\\Tomcat 5.5\\common\\lib
jmockit.dir=C:\\jmockit.jar

Quarto Passo: Para rodar o Ant (estou usando o Eclipse), clique com o botão direito no build.xml / Run As / Ant Build...

Na aba Targets, marque a target test e na aba Classpath, adicione o jar do JUnit.

A partir daí é só rodar.

Para o uso do JMockit adicionamos estas linhas (estão adicionadas nos exemplos acima, as linhas seguintes são somente informativas, porém se você não usar JMockit, remova-as):

No build.xml:
*sem o '$'
<$jvmarg value="-javaagent:${jmockit.dir}"/>
Adiciona o argumento na JVM.

No build.properties:
jmockit.dir=C:\\jmockit.jar
Indica onde está o jar do JMockit.

Problema com JMockit

2008-02-11T08:33:00.000-08:00

O JMockit foi comentado no post Mockando um Método Estático.

Bem, em algumas maquinas aqui da empresa, estava acontecendo o seguinte erro:

java.lang.VerifyError: (class: junit/framework/TestCase, method: runTest signature: ()V) Illegal constant pool index
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.getMethod0(Class.java:2611)
at java.lang.Class.getMethod(Class.java:1579)at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.
getTest(JUnit3TestLoader.java:99)at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.
loadTests(JUnit3TestLoader.java:59)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
runTests(RemoteTestRunner.java:445)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
runTests(RemoteTestRunner.java:673)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
run(RemoteTestRunner.java:386)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
main(RemoteTestRunner.java:196)

O interessante esta no trecho "em algumas maquinas", se o jar do JMockit e o método onde foi usado são os mesmos, por que somente em algumas maquinas aconteceu esse erro, e não em todas?

A verdade é que o erro não tem nada haver com JMockit, mas como faz parte do processo de fazer o JMockit funcionar, vou postar a minha solução aqui:

Li em vários lugares que o problema era causado pela JVM, que não suportava o parâmetro (figura abaixo). Onde li, dizia que o motivo era a quantidade de parâmetros passados pra JVM, e que era um problema da VM do Java 5. Não me aprofundei no assunto e nem pretendo.

O Runtime JRE, estava apontando para o diretório de uma JRE instalada, então apontei para o diretório da JDK e pronto, funcionou:

Caso este procedimento não seja suficiente para fazer com que seus testes funcionem, o problema pode ser da versão da sua JVM (a testada foi 1.5.0_08), instale outra e refaça o procedimento.

Confusões sobre Cobertura de Código

2008-02-07T08:23:00.000-08:00

Existem muitas idéias confusas sobre o conceito "100% de Cobertura", além das que já existentes no sentido de seguir ou não esta prática.

Começo esclarecendo que a Cobertura de Código é baseada em código coberto por Testes Unitários, pois um teste de Integração, por exemplo, testa telas, integração entre módulos, mas não analisa linhas cobertas.

Outra confusão é sobre a profundidade de um teste, quando tratamos deste assunto. Para que um método esteja 100% Coberto, o teste precisa somente passar por todas as suas linhas do código do método testado. Desta forma, o teste pode não ser completo, pois não testará "todas" as possibilidades, e mesmo assim será considerado 100% coberto. Com isso, não quero dizer que não devemos procurar a completude do teste.

A cobertura de código não garante, por si só, a qualidade no desenvolvimento, ter seu código 100% coberto é somente uma das várias práticas que lhe ajudam a obter sucesso no desenvolvimento.

Para garantir 100% de Cobertura, algumas vezes você será obrigado a fazer testes "inúteis", tomando o exemplo de meros getters e setters, esse é um dos motivos que faz com que algumas pessoas não "gostem" da idéia.

Manter seu código 100% Coberto é uma tarefa muito questionada, em várias situações quando nos preocupamos apenas com a arquitetura da nossa aplicação, preferimos não manter o código 100% Coberto. Porém, essa decisão tem efeitos comerciais, e estes também devem ser considerados.

Teste Unitário - Como definir o seu escopo?

2008-01-24T12:37:00.000-08:00

Quando se está começando a fazer testes, o assunto mais incompreendido é "até onde o teste unitário deve testar". Muitos confundem a idéia de unidade, e até começar a usar Mock Objects é um passo gigantesco e confuso.

Definições encontradas na WEB:

"O teste unitário ou de unidade é uma modalidade de testes que se concentra na verificação da menor unidade do projeto de software."
"Este estágio tem foco na verificação dos menores elementos testáveis do software."
"O teste unitário se limita a testar uma única unidade isolada."

Todas estão certas, e a minha definição para essa categoria de testes é: "Um teste que não ultrapassa a responsabilidade do método testado".

O que quer dizer que, não podemos ultrapassar a responsabilidade do método, da classe ou da camada. O negócio exige bom senso, pois um exemplo de quando ultrapassar a barreira do método é no caso de testar Métodos Privados, porém os escopos se confundem nesses casos.

Situações mais claras são quando tratamos classes diferentes, por exemplo:

Temos uma classe (ClassePeba) e testamos um método (getAlgo) desta classe:

 0: public class ClassePeba {
1:  public String getAlgo(int i){
2:   String palavra = "blablabla";
3:   ClasseCriptografa classeCriptografa =
4:    new ClasseCriptografa();
5:   palavra = classeCriptografa.criptogravaPalavra(
6:     palavra, i);
7:   return palavra;
8:  }
9: }

o método (getAlgo) invoca um outro método (criptogravaPalavra) de outra classe (ClasseCriptografa):

 0: public class ClasseCriptografa {
1:  public String criptogravaPalavra(String palavra, int i) {
2:   if(i == 1)
3:   {
4:    palavra = palavra.replace("a", "@");
5:    palavra = palavra.replace("b", "!");
6:    palavra = palavra.replace("l", "?");
7:   }else{
8:    palavra = palavra.replace("a", "*");
9:    palavra = palavra.replace("b", "$");
10:    palavra = palavra.replace("l", "%");
11:   }
12:
13:   return palavra;
14:  }
15: }

No teste do método (getAlgo):

 0: import org.junit.Before;
1: import org.junit.Test;
2: import static org.junit.Assert.*;
3:
4: public class TestClassePeba {
5:
6:  ClassePeba classePeba;
7:
8:  @Before
9:  public void prepare()
10:  {
11:  classePeba = new ClassePeba();
12:  }
13:
14:  @Test
15:  public void testGetAlgo()
16:  {
17:   assertEquals("!?@!?@!?@", classePeba.getAlgo(1));
18:   assertEquals("$%*$%*$%*", classePeba.getAlgo(2));
19:  }
20: }

Estamos testando duas classes distintas, caso aconteça uma inconformidade na outra classe (ClasseCriptografa), o erro irá acontecer no teste do método getAlgo, que não tem erro algum.

Dessa forma, o que deve ser feito é:

Primeiro, faço uma Refatoração para não instanciar a classe dentro do método, o teste definiu o design do método:

0: public String getAlgo(int i,
1:  ClasseCriptografa classeCriptografa){
2:
3:  String palavra = "blablabla";
4:  palavra = classeCriptografa.criptogravaPalavra(
5:    palavra, i);
6:  return palavra;
7: }

Crie um teste para o método getAlgo, mockando a classe ClasseCriptografa:

* para mockar uma classe com JMock, é necessário** criar a interface:

0: public interface ClasseCriptografiaInterface {
1:  public abstract String criptogravaPalavra(
2:    String palavra, int i);
3: }

** tambem é possível mockar uma classe concreta, veja aqui.

 0: import org.jmock.Mock;
1: import org.jmock.MockObjectTestCase;
2: import org.junit.Before;
3: import org.junit.Test;
4:
5: public class TestClassePeba extends MockObjectTestCase{
6:
7:  ClassePeba classePeba;
8:  Mock classeCriptografa = null;
9:
10:  @Before
11:  public void setUp()
12:  {
13:   classePeba = new ClassePeba();
14:   classeCriptografa = new Mock(
15:     ClasseCriptografiaInterface.class);
16:  }
17:
18:  @Test
19:  public void testGetAlgo()
20:  {
21:  classeCriptografa.expects(once()).
22:   method("criptogravaPalavra").
23:    with(eq("blablabla"), eq(1)).will(returnValue(
24:      "!?@!?@!?@"));
25:  assertEquals("!?@!?@!?@", classePeba.getAlgo(1, (
26:    ClasseCriptografiaInterface)classeCriptografa.
27:     proxy()));
28:
29:  classeCriptografa.expects(once()).method(
30:    "criptogravaPalavra").with(eq("blablabla"),
31:      eq(2)).will(returnValue("$%*$%*$%*"));
32:  assertEquals("$%*$%*$%*", classePeba.getAlgo(2,
33:    (ClasseCriptografiaInterface)classeCriptografa.
34:    proxy()));
35:  }
36: }

Até aqui o método criptogravaPalavra não foi sequer executado.

Depois criamos um teste específico para a classe ClasseCriptografa:

 0: import static org.junit.Assert.assertEquals;
1:
2: import org.junit.Before;
3: import org.junit.Test;
4:
5: public class TestClasseCriptografa{
6:
7:  ClasseCriptografa classeCriptografa;
8:
9:  @Before
10:  public void setUp()
11:  {
12:   classeCriptografa = new ClasseCriptografa();
13:  }
14:
15:  @Test
16:  public void testGetAlgo()
17:  {
18:   assertEquals("!?@!?@!?@", classeCriptografa.
19:     criptogravaPalavra("blablabla",1));
20:   assertEquals("$%*$%*$%*", classeCriptografa.
21:     criptogravaPalavra("blablabla",2));
22:  }
23: }

Pronto!

A idéia é ter seus testes bem separados, pois em momentos de refatoração, encontrar os erros do método e a alteração do próprio teste será facilitada.

TestNG - Uma ótima alternativa

2008-01-22T12:37:00.000-08:00

O TestNG é uma ferramenta largamente utilizada para fazer Testes de Unidade (pelo que andei ouvindo, até mais que isso), aqui na empresa, o Israel Freitas usa essa ferramenta e tenta a muito tempo evangelizar outros, porém pouco lhe dei ouvidos, "já que eu tenho o JUnit pra que procurar outra ferramenta que faz a mesma coisa de maneira diferente" ? Mas por insistência dele, resolvi fazer um teste e publicar algo sobre o assunto, confesso que minha opinião sobre o TestNG mudou de maneira drástica.

Esta ferramenta foi criada por Cédric Beust (a senior software engineer at Google) e Alexandru Popescu, esta já usa conceitos como Annotations bem antes do JUnit, além disso, percebi muitas funcionalidades e facilidades oferecidas por ele.

Um conceito interessante é o de dependência entre testes, vale a pena ser estudado.

O TestNG (a versão testada é a 5.6) permite a utilização dos asserts do JUnit, inserindo somente o import: import static org.testng.AssertJUnit.*;

Para ilustrar, criei um exemplo bem simples:

Foi criado a classe POJO somente com 2 atributos e seus getters e setters:

 0: public class POJO {
1:
2:  private int id;
3:  private String nome;
4:
5:  public int getId() {
6:   return id;
7:  }
8:  public void setId(int id) {
9:   this.id = id;
10:  }
11:  public String getNome() {
12:   return nome;
13:  }
14:  public void setNome(String nome) {
15:   this.nome = nome;
16:  }
17: }

Um teste bem simples foi feito pra a classe:

 0: import org.testng.annotations.*;
1: import static org.testng.AssertJUnit.*;
2:
3: public class POJOTest{
4:
5:  @BeforeClass
6:  public void setUp() {
7:  }
8:
9:  @Test
10:  public void gettersAndSettersTest()
11:  {
12:   POJO pojo = getEntidade();
13:   assertEquals(pojo.getId(), 1);
14:  }
15:
16:  private POJO getEntidade() {
17:   POJO pojo = new POJO();
18:   pojo.setId(1);
19:   pojo.setNome("nome");
20:   return pojo;
21:  }
22: }

* Perceba que uso os asserts do JUnit.

Criei o arquivo de configuração do TestNG:
*tire os '$' de todas as linhas

<$!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<$suite name="My First TestNG test">
<$test name="Hello Test!">
<$classes>
<$class name="POJOTest" />
<$/classes>
<$/test>
<$/suite>

Utilizando o plugin para o Eclipse rodei este teste com extrema facilidade e o log do resultado foi gerado:

[Parser] Running:
C:\Arquivos de programas\Apache Software Foundation\Tomcat 5.5\webapps\TestNGExamples\temp-testng-customsuite.xml

PASSED: gettersAndSettersTest

===============================================
POJOTest
Tests run: 1, Failures: 0, Skips: 0
===============================================

===============================================
TestNGExamples
Total tests run: 1, Failures: 0, Skips: 0
===============================================

O nível de detalhes do log do resultado é determinado na propriedade "Log Level" da configuração da execução do TestNG.

Os links abaixo vão ajudar muito na utilização do TestNG.

Site oficial
Plugin pro Eclipse
Annotations pra todos os gostos
TestNG com Ant
Automatizando a Migração do JUnit para o TestNG
Comparação entre TestNG e JUnit4
Bom artigo sobre o assunto

Avaliação geral:

Como um usuário do JUnit, considero o TestNG um adversário de peso, bem mais rico quando se fala de annotations. Acredito que esta ferramenta deve ter seu uso considerado, além de ser muito robusta e cheia de novidades, tem muita documentação disponível na WEB.
A única carência que percebi, foi a ausência de asserts, porém com introdução dos asserts do JUnit a carência foi resolvida.

Teste de Regressão

2008-01-18T18:10:00.000-08:00

Sempre escuto falar nesse tal, e achando que não teria tempo para estudar mais uma "novidade" no mundo dos testes, fui adiando, adiando até a curiosidade me forçar a procurar algo sobre o assunto. Daí vi essa definição:

"O Teste de Regressão consiste na aplicação de testes à versão mais recente do software, para garantir que não surgiram novos defeitos em componentes já testados. Se ao juntar o novo componente ou as suas alterações com os restantes componentes do sistema, surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu."

Vi este outro conceito também:

"Os testes automáticos têm uma vantagem em relação aos manuais: são facilmente repetíveis. Portanto, são favorecidos no momento dos testes de regressão."

Dessa forma, percebi que faço testes de regressão várias vezes ao dia, sempre que pratico Integração Contínua, percebi também a força deste conceito e que é muito fácil ter Testes de Regressão, basta manter os testes criados no TDD e a Integração Contínua acontecendo de maneira sistemática.

Uma dica para quem está começando é: Não faça esses testes de forma manual, automatize.

Passagem de vários parâmetros para método mockado

2008-01-16T08:37:00.000-08:00

De acordo com o post Passagem de parâmetros para método mockado, a quantidade de parâmetros passados para o método mockado deve ser igual a do método "de verdade", desta forma encontrei um problema esta manhã:

Tinha um teste para um método, e nele, mockava um método de um outro objeto da seguinte forma:

historicoClienteDao.expects(once()).method("findByFiltros").with(1L, "nome", null, 3L).will(returnValue(historicos));

porém, este método ganhou mais um parâmetro e quando o adicionei, deu erro de compilação:

historicoClienteDao.expects(once()).method("findByFiltros").with(1L, "nome", null, 3L, true).will(returnValue(historicos));

pois o método with só recebe 4 Constraints.

Aí foi que percebi que ele também recebe um array de Constraints e então o "problema" foi resolvido da seguinte forma:

historicoClienteDao.expects(once()).method("findByFiltros").with(new Constraint[]{1L, "nome", null, 3L, true}).will(returnValue(historicos));

ps. a ferramenta usada neste exemplo é o JMock.

TDD - Os testes devem ser feitos antes ou durante a implementação?

2008-01-13T17:03:00.000-08:00

A resposta é clara, DURANTE. Porém, existem vertentes que tratam o "DURANTE" de maneira mais ou menos radical, bem vou tentar explicar o conceito:

A vertente 1 acredita que o código de testes deve ser feito "ao mesmo" tempo que a implementação da funcionalidade. Bem, sejamos mais claros, os praticantes dessa vertente acreditam que deve ir descobrindo o que o método vai fazer a medida que o vai escrevendo.

Nessa abordagem, o FeedBack é mais rápido.

leitura recomendada

A vertente 2 considera a possibilidade de começar "ANTES" e continuar "DURANTE".

Num comentário do Thiago Arrais sobre a leitura recomendada acima, a idéia de fazer o teste "DURANTE" a implementação tem um conceito menos literal, veja a frase: "Escreva os testes que conseguir imaginar antes de começar a escrever o código...".

Como o próprio Thiago se preocupa em "não demorar demais pensando", esta técnica deve ter este cuidado tomado, então concluímos essa abordagem como:

Faça os testes que você idealizou imediatamente, como num validador de PDF, essa técnica diz, por exemplo, que você já pode fazer os testes pra dois CPFs diferentes(um certo e um errado), antes mesmo de implementar a primeira linha do código do validador, você também pode testar um CPF com menos dígitos, com mais dígitos, etc.

Nessa abordagem, a maior vantagem é "pensar mais" antes de começar a implementação.

Eu sou um seguidor da segunda vertente, isso porque considero mais fácil de fazer e obtive melhores resultados fazendo dessa forma, porém não sou nada radical quanto a isso, acredito que existam várias situações em que a primeira vertente seja mais indicada. Também não acho que exista a "forma certa" de fazer, o certo é que vale a pena ser feito.

TDD - Testes são somente a consequência

2008-01-13T17:00:00.000-08:00

Pois é, você pode até ter ouvido isso em outro lugar, mas existe uma grande chance de você ter "descoberto" antes mesmo de ouvir.

Sei que é óbvio, mas como vejo muita gente confundindo o "processo" de TDD com Testes Unitários, resolvi dar minha contribuição.

O TDD tem como objetivo dirigir o design da implementação, essa é, sem dúvida, o maior lucro de usar TDD. O segundo maior lucro é ter sua aplicação coberta por testes.

Tendo suas implementações dirigidas por testes, estes se tornam parte da sua aplicação, pra ser mais claro, o código desenvolvido na classe de teste passa a funcionar "até mesmo" como documentação, além do óbvio, que é o fato da sua implementação ter sido baseada no teste. Um método pode, em muitas situações, ter sua implementação modificada pra facilitar o teste.

Por que a confusão(TDD X Testes Unitários) acontece?

Simples, porque fazer TDD é fazer Teste Unitário. Porém, você pode fazer o teste unitário após a funcionalidade estar concluída e isso não é TDD, você terá seu código 100% coberto, mas como já falei, o beneficio maior é dirigir a implementação, ter seu código 100% coberto é apenas a consequência de fazer TDD.

Testando Actions do WebWork 2

2008-01-10T13:15:00.000-08:00

No site da opensymphony tem um artigo mostrando como Testar Actions do WW, como não entendi direito, pedi um auxílio ao Igo Coelho e vi que o negócio é mais simples do que parece.

Para testar Actions, não precisamos estender nada, porém temos que ficar atentos com as variáveis da classe, pois essas terão que ser informadas.

1) Pra começar, crie uma instancia da Action a ser testada:

private ArtigoEditAction action;

é essa variável que será utilizada para invocar os métodos, como também, setar as variáveis da Action.

2) setUp e tearDown pra deixar as coisas nos seus lugares:

 0: protected void setUp() throws Exception
1: {
2:  super.setUp();
3:  action = new ArtigoEditAction();
4: }
5:
6: protected void tearDown() throws Exception
7: {
8:  action = null;
9:  super.tearDown();
10: }

3) A grande maioria desses testes consiste apenas em verificar o direcionamento:

0: public void testExecute() throws Exception
1: {
2:  assertEquals(action.execute(), "success");
3: }

4) Como as Actions não retornam os objetos que usaremos nas páginas, eles são populados e passados por request (eu acho), é importante verificar o estado da variável:

para o método:

0: public String listNormas() throws Exception
1: {
2:  artigo = artigoManager.findById(artigo.getId());
3:  return Action.SUCCESS;
4: }

a variável artigo é alterada, então não devemos testar somente o retorno, devemos testar também o estado dessa variável após o método ser executado:

 0: public void testList() throws Exception
1: {
2:  Artigo artigo = new Artigo();
3:  artigo.setId(1L);
4:
5:  Artigo artigoCheio = new Artigo();
6:  artigoCheio.setId(1L);
7:  artigoCheio.setResumo("resumo");
8:
9:  action.setArtigo(artigo);
10:
11:  artigoManager.expects(once()).method("findById").
12:  with(eq(artigo.getId())).will(returnValue(artigoCheio));
13:
14:  assertEquals(action.getArtigo().getResumo(), null);
15:  assertEquals(action.listNormas(), "success");
16:  assertEquals(action.getArtigo().getResumo(), "resumo");
17: }

5) Para efeito de 100% de cobertura, eventualmente você terá que forçar umas chamadas de get ou set de alguma propriedade, pois é bem possível que esta não seja invocada naturalmente:
* Um plugin como o eclEmma pode te ajudar muito nessas horas.

 0: public void testCobrirGetsSets()
1: {
2:  Collection vendedores = new ArrayList();
3:  action.setVendedores(vendedores);
4:  action.getDataFinalVendas();
5:  action.getProdutoPacotes();
6:  action.getProdutoPacote();
7:  action.getDataInicioVendas();
8:  action.getVendedor();
9: }

* sei que é horrível, mas é melhor um teste feio do que não ter o teste.

Só isso, fácil fazer teste para as Actions, né!? :P Se encontrar alguma dificuldade postarei aqui, mas acabou a desculpa de não fazer testes nas Actions.

Boas práticas - Parte I

2008-01-09T17:09:00.000-08:00

Hoje, desenvolvendo algumas funcionalidades que faziam consultas ao BD, percebi que existem algumas técnicas que podem facilitar a implementação e fortalecer os testes, por isso decidi criar a sessão Boas práticas.

Neste post vou falar sobre boas práticas em testes para consultas.

Se você estiver usando SQL "puro" talvez não tenha tanto problema (mesmo achando que essas boas práticas devem ser seguidas) mas usando APIs de persistência, como Hibernate, essas práticas se fazem quase obrigatórias:

O caso de uso é trazer todas as operações ocorridas entre duas data (os dias 10 e 20 de dezembro, por exemplo).

* crie testes com valores nos limites.
crie registros ocorridos exatamente em cada uma das datas (10 e 20 de dezembro).

* crie testes com valores intermediários.
crie um registro, pelo menos, ocorrido numa data intermediária (dia 15, por exemplo).

* crie testes com valores imediatamente fora dos intervalos.
crie registros ocorridos nas datas vizinhas as limites(9 e 21 de dezembro).

* se houverem mais campos condicionais, como por exemplo "Tipo de Operação", crie registros que "contrariem" somente essa condição.
isso é muito útil em sistemas multi-empresa.

Lógico que existem várias outras boas práticas (por isso postei no título: Parte I), e sempre que lembrar vou tentar postá-las aqui.

ps. Se você tem mais boas práticas e quiser vê-las neste blog, óbvio que eu preciso concordar com elas, me envie por email (esta lá em "Quem sou?").

Testes dirigem o design

2008-01-08T03:52:00.000-08:00

Pois é, esses dias tive uma discussão na xprio sobre um teste que estava bem complicado, isso contraria várias idéias de que os testes não devem ser tão complicados de implementar, o que é verdade, eles não devem ser complicados, bem, o caso era o seguinte:

Estava testando um método:

0: public void enviaEmail()
1: {
2:  // faz um monte de coisa
3:  Mail mail = new Mail();
4:  mail.send("Titulo", "Corpo", "email@email.com.br");
5:
6:  // faz outro monte de coisa
7: }

Dentro deste método, crio a instância de outra classe(Mail) e invoco o método(send) desta. Aí esta o problema, este método(send) envia emails, e isso é algo que não preciso que meu teste faça.

O Danilo Sato levantou esta bola(o teste dirige o design), e me fez algumas perguntas:

* Que tal passar o e-mail pronto como parâmetro?
* Vale a pena ter o e-mail como atributo dessa classe?
* Qual a responsabilidade dessa classe que está testando? enviar o
e-mail ou criar o email?

Essas perguntas podem ser generalizadas e usadas em situações onde o teste se torne mais complicado.

Como se trata de uma situação onde o código já existe e funciona, fazer uma refatoração é o mais indicado a fazer, nada de grandes manobras, apenas desacoplar algumas funcionalidades ou a criação do objeto, como me indicou o Celestino, com um getInstance por exemplo.

De qualquer forma, fica a lição de que o teste feito quando usamos TDD é normalmente, pra não dizer: sempre, mais simples.

Devo testar os métodos que não alteram parâmetros nem retornam nada?

2008-01-07T12:54:00.001-08:00

Isso é uma questão meio filosófica, pois, qual a necessidade de testar um método que não "faz nada" ?

Bem, se você ainda não imaginou a situação, lá vai um método da classe Manager:

0: public void reordenar(Object obj, boolean up)
1: {
2:  getDao().reordenar(obj,up);
3: }

Com certeza o método reordenar da classe Dao faz muita coisa, e o teste dele será bem útil (sem nenhuma dúvida), mas o que faço com o método reordenar da classe Manager?

Começando pela premissa de que tudo pode e deve ser testado, então, devemos implementar um teste para este método.

Neste caso em particular, o método é muito simples, mas ele poderia não ser e ter a mesma característica, então, consideremos as várias possibilidades de quebra:

Primeiro imagine, que em qualquer parte do código pode haver um objeto nulo, como neste caso o getDao() poderia tranquilamente retornar null e disparar um NullPointerException na sequência.

Desta forma, é preferível fazer o teste sem nenhum "assert", porém, cobrindo cada linha do método:

0: public void testReordenar()
1: {
2:  Object obj = new Object();
3:  classeDao.expects(once()).method(
4:    "reordenar").with(eq(obj),
5:      eq(true));
6:  classeManager.reordenar(obj, true);
7: }

Se você encontrar outra forma de fazer o teste e achar melhor, faça, mas não deixe de fazê-lo em hipótese alguma.

Seja "descuidado" com seus testes

2007-12-20T03:43:00.000-08:00

Primeiramente, perceba que o "descuidado" está entre aspas(" "), com isso quero dizer que ele tem uma razão de existir, e que, óbvio, você não deve negligenciar seus testes.

Me refiro a ser descuidado com "verificações" que fazemos para evitar exceções, como:

- verificar se um objeto é null, para não dar NullPointerException;
- no caso de um Array, verificar se existem elementos antes de tentar pegar a posição 0 ou 1 ou qualquer outra;
- verificar divisões por zero;
- problemas com cast;
- e outros.

Bem, listei acima os que me vieram a cabeça no momento, mas, com certeza, existem muitos outros.

A dica que quero deixar é que abuse dos testes sem fazer "qualquer" dessas verificações, um teste feito com esse "descuido" pode capturar erros que precisariam de várias verificações para serem encontrados. Esses cuidados devem ser tomados no código do seu método (funcionalidade).

Claro que você pode criar métodos que esperam uma exceção, e isso deve ser verificado com maior zelo, mas se este não é o objetivo, e exceções são eventuais, seja "descuidado".

Como testar um Método Privado?

2007-12-19T12:44:00.000-08:00

Pra começar, surgem duas perguntas:

Devo Fazer? Como devo fazer?

A primeira resposta é: Claro que sim, se ele pode quebrar, ele deve por motivo óbvios, e se não pode quebrar, ele deve por motivos estratégicos.

A segunda resposta é: Aí depende. Depende da linguagem, da capacidade do desenvolvedor, do tempo, "beleza" do código, facilidade de manter, etc.

Pra tentar deixar mais claro, vamos considerar duas possibilidades:

- Testar Explicitamente o método privado;
- Testar por intermédio de outro método.

A primeira possibilidade, testar explicitamente, pode-se fazer duas coisas (que me vem a mente, mas podem existir outras):

- Você pode trocar a visibilidade do método para public com Reflection, em tempo de execução;
- Alterar o método para protected. Isso é mais complicado, em casos de código legado ou sistemas de outros.

A segunda possibilidade, a que prefiro, é usar outro método "testável" para testar o método privado.

Na prática, é muito fácil perceber isso, mas vai que você quer entender logo o que estou falando, então vai um exemplo:

Tenho uma classe com um método public (que retorna uma String) e um private, o método private (criptografa a palavra blablabla)

 0: public class ClassePeba {
1:  public String getAlgo(int i)
2:  {
3:   String palavra = "blablabla";
4:   palavra = criptografaPlavra(palavra, i);
5:   return palavra;
6:  }
7:
8:  private String criptografaPalavra(String palavra,
9:    int i) {
10:   if(i == 1)
11:   {
12:    palavra = palavra.replace("a", "@");
13:    palavra = palavra.replace("b", "!");
14:    palavra = palavra.replace("l", "?");
15:   }else{
16:    palavra = palavra.replace("a", "*");
17:    palavra = palavra.replace("b", "$");
18:    palavra = palavra.replace("l", "%");
19:   }
20:   return palavra;
21:  }
22: }

O método private (criptografaPalavra) será testado por intermédio do método public getAlgo
Veja os comentários no código:

 0: public class TestClassePeba {
1:
2: ClassePeba classePeba;
3:
4:  @Before
5:  public void prepare()
6:  {
7:   classePeba = new ClassePeba();
8:  }
9:
10:  @Test
11:  public void testGetAlgo()
12:  {
13:   //fazendo este teste, o método getAlgo
14:   //já está 100% coberto
15:   assertEquals("!?@!?@!?@", classePeba.
16:     getAlgo(1));
17:   //fazendo este teste, o método
18:   //criptografaPalavra também fica 100% coberto
19:   assertEquals("$%*$%*$%*", classePeba.
20:     getAlgo(2));
21:  }
22: }

Acho que fica claro o motivo pelo qual, considero esta abordagem a mais indicada, ela é mais simples, fácil de implementar e de manter, e não a considero nem um pouco deselegante.

ps. Por favor, não reparem o método de criptografar, criei só pra demonstração.

CruiseControl - Automatizando minha Integração Continua

2007-12-19T03:52:00.000-08:00

Ouvi muito se falar de CruiseControl, até mesmo aqui na empresa já estudamos a sua viabilidade. Mas, o que eu ganho com isso?

Uma integração "simples": test, backup, update, test, commit, pode ser executada com um botão ao lado do commit, então não dou "cliques a mais".

Mas lá vem uma vantagem, não preciso esperar a integração acontecer, sendo que ela pode demorar um pouco, aqui na empresa ela dura mais ou menos 5 minutos.

E como ouvi alguem me dizer, "sua maior força é sua maior fraqueza", então: a vantagem descrita acima acarreta no maior defeito, em minha opinião, de Automatizar a minha Integração Contínua, o feedback rápido é perdido.

Eu posso configurar o CruiseControl para me avisar mais rapidamente, posso saber 1 minutos após dar um erro, porém, mas se você estiver fazendo a integração "na mão" e o erro acontecer, você o corrigirá imediatamente.

E caso o gerente receba um email que a integração quebrou, duvido que ele diga, "parem o que esta sendo feito e verifiquem a integração".

Pior que isso, mesmo que o gerente peça para corrigir, é que se duas pessoas jogarem erros que provoquem "quebra" na integração, a pessoa que for corrigi-la pode conhecer apenas um dos erros e a demora para a correção desses erros é maior que seria caso a Integração fosse feita "na mão".

A dificuldade de correção pode acarretar num grande problema, o repositório pode ficar muito tempo quebrado.

O Vinícius da ImproveIT escreveu num post sobre Barrigas Abertas a seguinte frase: "Nos projetos que eu conheci, que utilizavam CruiseControl, era comum o repositório estar quebrado.", isso já me parece motivo suficiente para não usar essa Automatização.

Dois bons links sobre Integração Contínua e CruiseControl:

http://www.improveit.com.br/xp/praticas/integracao
http://weblogs.pontonetpt.com/contracorrente/posts/2008.aspx

Livros sobre Testes (em inglês)

2007-12-18T03:57:00.000-08:00

Muita gente procura referencias para estudar testes, e numa lista de discussão sobre Java indicaram o site flazx.

Como não me pareceu pirataria, até por ter o link para comprar na Amazon e tal, listei aqui em baixo, alguns livros sobre testes que tratam de assuntos bem interessantes:

http://www.flazx.com/ebook2330.php
http://www.flazx.com/ebook2721.php
http://www.flazx.com/ebook4275.php
http://www.flazx.com/ebook8592.php
http://www.flazx.com/ebook2630.php
http://www.flazx.com/ebook1369.php

Com as férias chegando, esta é uma boa oportunidade para aperfeiçoar, aprender ou conhecer algo mais sobre testes.

* Também é uma boa oportunidade de estudar Inglês.

Valeu a dica, Barroso.

TDD - Auxiliando a desenvolver consultas com Hibernate + Spring

2007-12-18T03:23:00.001-08:00

Quando usamos sql "puro", testar uma consulta é muito simples de ser feito, pois podemos utilizar uma ferramenta de BD como o MySQL Admin, ou PGAdmin, porém quando usamos APIs de Persistência, o problema aparece.

Esses dias, num caso de uso que necessitava de uma consulta nem tão complexa, tive que startar e re-startar o servidor de aplicação 8 vezes, para testar a consulta que era montada.

Daí, fiquei pensando se TDD poderia me ajudar, e ví que ele pode me ajudar e muito.

Usando TDD para o desenvolvimento de uma consulta, além de diminuir o tempo perdido com o servidor de aplicação sendo levantado e derrubado várias vezes, ainda ganho o tempo de abrir a aplicação, preencher campos (como um filtro por exemplo) e submeter um formulário.

Para fazermos TDD com consultas, precisamos gerenciar as transações para garantir que determinadas informações estarão na base de dados e outras não sejam persistidas.

Utilizando Hibernate + Spring precisamos extender a classe AbstractTransactionalSpringContextTests do Spring, para gerenciar as transações.

extends AbstractTransactionalSpringContextTests

No método de testes devemos escrever o método getConfigLocations para carregar os arquivos de contexto do Spring:

0: @Override
1: protected String[] getConfigLocations()
2: {
3:  setAutowireMode(AUTOWIRE_BY_NAME);
4:  return new String [] {"applicationContext*.xml"};
5: }

No método de teste, você insere registros para simular um banco de dados populado:

 0: public void testGetAvisosMesAno()
1: {
2:  Aviso a1 = new Aviso();
3:  a1.setId(1L);
4:  a1.setData(new Date(107, 11, 1));
5:
6:  Aviso a2 = new Aviso();
7:  a2.setId(2L);
8:  a2.setData(new Date(107, 10, 1));
9:
10:  Aviso a3 = new Aviso();
11:  a3.setId(3L);
12:  a3.setData(new Date(107, 11, 20));
13:
14:  avisoDao.save(a1);
15:  avisoDao.save(a2);
16:  avisoDao.save(a3);
17:
18:  Collection avisos = avisoDao.
19:   getAvisosMesAno(new Date(107, 11, 1),
20:     new Date(107, 11, 30));
21:  assertEquals(2, avisos.size());
22: }

Se já existirem dados no banco, o tamanho do retorno (avisos.size()) não é um bom teste, é melhor verificar se os elemento que deseja, estão lá, e se os que não deseja, não estão.

A lição que deve ser deixada é que TDD é tão ou mais útil para um método de persistência do que para um método de negócio.
O "ou mais" é o que acho que se encaixa melhor, pois imagine a possibilidade de errar na criação de uma consulta, além de tudo, usamos muito "palavras" que não são compiladas, como o nome de campos da sua classe.

Outra dica é que mesmo usando SQL puro, o TDD pode conduzir muito bem a construção da sua query, e acho que mesmo sendo fácil testar a consulta com outras ferramentas, o TDD pode trazer mais benefícios do que, simplesmente, testar a consulta.
Veja também o post sobre 100% de Cobertura.

JMockit - Mockando um Método Estático

2007-12-14T07:59:00.000-08:00

É com grande felicidade que consegui, nesta manhã de sexta, mockar um método estático, p&#@ que p@$%&, sensacional.

O nome do cara é JMockit

Bem, o meu exemplo é bem simples:

Criei uma classe que tem somente um método estático, é esta classe que quero mockar:

0: public class ClasseUtil {
1:  public static int metodoEstatico()
2:  {
3:   return 1;
4:  }
5: }

Então, uma classe que utiliza este método:

0: public class ClasseFuncionalidade {
1:  public static int metodoLocal()
2:  {
3:   return ClasseUtil.metodoEstatico();
4:  }
5: }

Por fim, a classe de teste:

 0: public class ClasseFuncionalidadeTeste{
1:
2:  public static class MockClasseUtil{
3:   public static int metodoEstatico()
4:   {
5:    return 0;
6:   }
7:  }
8:
9:  @Before
10:  public void prepare(){
11:   Mockit.redefineMethods(
12:     ClasseUtil.class,
13:     MockClasseUtil.class);
14:  }
15:
16:  @After
17:  public void finalize(){
18:   Mockit.restoreAllOriginalDefinitions();
19:  }
20:
21:  @Test
22:  public void metodoLocal(){
23:   assertEquals(0, ClasseFuncionalidade.
24:     metodoLocal());
25:  }
26: }

Perceba que criei uma outra classe (inner class) chamada MockClasseUtil, com um método (metodoEstatico) de mesma assinatura do método da classe ClasseUtil, porém o retorno é diferente (No original é 1 e no falso é 0).

Redefino os métodos da classe real pelos da classe mock:

0: @Before
1: public void prepare(){
2:  Mockit.redefineMethods(
3:    ClasseUtil.class,
4:     MockClasseUtil.class);
5: }

Se fosse no JUnit3, poderia usar o método setUp para invocar o redefineMethods.

E para voltar "ao normal":

0: @After
1: public void finalize(){
2:  Mockit.restoreAllOriginalDefinitions();
3: }

A única dificuldade foi "ver" que o comando "-javaagent:jmockit.jar" deve ser passado como parâmetro para a JVM:

No eclipse é só fazer isso, na hora de rodar o teste:

ou isso, para rodar com test suite ou qualquer outro lugar:

JUnit4 - Suite de Testes

2007-12-13T08:45:00.000-08:00

Para provar, ainda mais, que o JUnit4 veio "apaixonado" por annotations, lá vai mais uma da série: JUnit4 - Novidades e Melhorias.

Vou mostrar um exemplo de TestSuite nas duas versões, isso tornará a explicação clara:

Para criar uma suite de testes com JUnit3:

 0: public class AllTests extends TestSuite
1: {
2:  public static TestSuite suite()
3:  {
4:   TestSuite suite = new TestSuite();
5:
6:   suite.addTestSuite(ClasseFuncionalidadeTeste.class);
7:   suite.addTestSuite(CopyOfClasseFuncionalidadeTeste.
8: class);
9:  }
10: }

Agora, com JUnit4:

0: @RunWith(value=Suite.class)
1: @SuiteClasses(value={
2:  ClasseFuncionalidadeTeste.class,
3:  CopyOfClasseFuncionalidadeTeste.class
4:  }
5: )
6: public class TestAll {
7: }

Bem, com JUnit4, a classe "suite" só existe para "receber" a annotation e ser executada, não necessitando de nenhum método.

JUnit4 - Novidades e Melhorias

2007-12-10T03:14:00.000-08:00

Neste fim de semana estava trabalhando em uma aplicação pessoal e tentei usar o JUnit4 para criar meus testes.

Primeiro que tive uma surpresa ótima, os meus métodos de teste criados para JUnit3 funcionam no JUnit4.

O JUnit4 veio com uma aplicação muito forte de Annotations, irei listar as que vi e percebi serem de maior importância:

@Test - O JUnit4 somente necessita da annotation @Test para identificar um método de teste.
@Before e @After - Outras novidades são as annotations @Before e @After, como o nome já diz, são métodos invocados antes e depois dos métodos de teste.

Ainda sobre a annotation @Test, esta recebe parâmetros e 2 que descobri são realmente incríveis:

expected - este parâmetro serve para testar Exception, somente é necessário informar na annotation qual Exception é esperada e pronto: @Test(expected=IOException.class).
timeout - este serve testar tempo de execução do teste, onde o teste falha se demorar mais que o tempo informado: @Test(timeout=2000).

Com JUnit4, uma classe de teste não extende TestCase e seus métodos não precisam começar com "test", como já foi dito, usa-se @Test.

Foram adicionados 2 novos asserts:

O assertEquals com um par de arrays que podem ser passados como parâmetro, desta forma o método verifica cada elemento: assertEquals(Object[] o1, Object[] o2);
E o assertEquals que recebe um primeiro parâmetro String e um par de arrays, este primeiro parâmetro aparece ao lado do erro, caso o teste falhe, permitindo a identificação da linha exata onde o teste falhou: assertEquals(String message, Object[] obj1, Object[] obj2);

Um exemplo básico e que mostra o que deve ser feito para que sua classe de teste feita em JUnit3 se adeque a nova versão do JUnit:

 0: //Com JUnit3
1: public class HelloWorld extends TestCase
2: {
3:  //necessita do prefixo "test"
4:  public void testSoma()
5:  {
6:   // Testa se 1+1=2:
7:   assertEquals (2, 1+1);
8:  }
9: }
10:
11: //Com JUnit4
12: public class HelloWorld //Não extend TestCase
13: {
14:  @Test
15:  //não precisa ter este nome, poderia ser soma()
16:  public void testSoma()
17:  {
18:   // Testa se 1+1=2:
19:   assertEquals (2, 1+1);
20:  }
21: }

100% de Cobertura - Até quanto isso é importante?

2007-12-07T11:41:00.000-08:00

Existe um embate violento sobre este assunto, outro dia participei de uma discussão na xp-rio (ótima lista de discussão sobre XP), com alguns feras do XP no brasil sobre isso. Bem, é certo que fazer testes é importante, mas devo usar a métrica de 100% de cobertura?

Vi várias opiniões, a minha começou com: "Só devo cobrir os métodos mais complicados", depois ouvi uma boa argumentação que me fez pensar assim: "Só devo cobrir o que pode quebrar". Desta forma, um método que apenas chama outro, não terá nenhum teste. Mas ele precisa?

Prefiro dizer que ele "não precisa", pois se algo fizer este método quebrar, o compilador me avisa.

Então, conversando com o Tales (meu gerente e figura conhecida no meio ágil), percebi a necessidade de garantir a qualidade para o cliente, como nos métodos tradicionais é usado um CMMI ou MPS-Br ou ISO, as metodologias ágeis são carentes nessa área e vez por outra precisam de alguma métrica para mostrar a qualidade, e na minha opinião, ter 100% de linhas de código cobertas por testes, me garante MAIOR qualidade num produto do que CMMIs ou ISOs da vida.

Por fim, este argumento não pôde ser rebatido, sabemos que testes são bons, e que se iremos perder 10 minutos, ou menos, fazendo um teste que nunca irá quebrar, e que será, no mínimo, parte de uma métrica de qualidade, por que não fazê-lo?

Que fique claro que não concordo que um "teste ruim" seja melhor que não ter teste. Mas isso fica pra outra blogada.

JMock versus Classes Concretas 2 - A Missão

2007-12-06T03:20:00.000-08:00

Me recuperando da decepção da incompatibilidade de versões do JMock, ví que o JMock 1 pode mockar classes concretas.

Baixei o jmock-cglib-version.jar, e fiz como diz no link abaixo:

http://www.jmock.org/jmock1-cglib.html

e funcionou.

A única limitação é que não pode ser uma classe final.

JMock acaba de recuperar seus pontos.

Thanks, Nat Pryce.

TDD - Um exemplo prático

2007-12-05T15:16:00.000-08:00

No início, via sempre o exemplo de validação de cpf, as vezes me pegava pensando, será que pra casos "não matemáticos" isso vai funcionar?

Hoje, no trabalho, desenvolvendo um método bem simples, resolvi tirar os "print screen" pra postar aqui e mostrar pros iniciantes em TDD que o assunto em bem próximo da nossa realidade.

Segue o exemplo abaixo:

Dada uma Collection de AtoNormativo* e um objeto do tipo AtoNormativo, façamos um método que retorne a Collection de AtoNormativo excluindo o objeto passado.
*AtoNormativo é uma classe e tem uma propriedade Long id.

1) Crio o método retiraNorma passando uma Collection e um AtoNormativo;

2) Crio o método testRetiraNorma, crio a Collection, adiciono 3 objetos do tipo AtoNormativo e chamo o método retiraNorma, passando um dos objetos inseridos, para ser retirado da Collection.

Perceba que após chamar o método, testo se a Collection foi retornada com 2 elementos somente, se um objeto que não deve ter sido removido, não foi removido, e se um objeto que deve ter sido removido, foi removido.

3) Rodei o teste e deu erro. É o que deve acontecer, já que o método ainda retorna Null.
Implemento o método.

4) Rodo o teste e tudo ok.

A barra verde no canto esquerdo superior da imagem é o sinal de sucesso.

Pronto.

Perceba que a sequência lógica se mantém, penso no que vou fazer, penso no que o método deve fazer, implemento e testo, porém, quando o teste é rodado, você não precisa mais rodar a aplicação, abrir uma determinada tela e executar um certa funcionalidade, o teste garante que, na situação que você pensou, o método irá funcionar.

Perceba que o teste pode ser alterado, podem ser inseridos situações em que o objeto passado não está dentre os objetos da Collection, e isso pode ser feito, o teste não é final, ele sempre pode evoluir.

TDD - Desenvolvimento Orientado a Testes

2007-12-05T15:11:00.000-08:00

Quando ouvi a primeira vez sobre Test Driven Development achei imoral, o quão ridículo pode parecer fazer testes antes de desenvolver uma funcionalidade?

Bem, o negócio não é tão feio quanto parece, fazer TDD te ajuda em muita coisa.

Outro dia eu estava fazendo um Caso de Uso relacionado a uma loja virtual, onde deveria retornar vários valores de acordo com os produtos comprados.

Comecei fazendo o Teste:

Primeiro Passo: Gerei a classe de teste e criei somente a assinatura do método.
Segundo Passo: Fiz as simulações necessárias numa calculadora e amarrei no teste, de acordo com a entrada a saída deveria ser... Óbvio que o teste ainda não funcionava.
Terceiro Passo: Parti para a implementação, encontrei menos dificuldades do que imaginava, a lógica estava na minha cabeça, e quando imaginei ter terminado a funcionalidade, simplesmente rodei o teste.

Corrigindo os erros que encontrei no teste e corrigindo o próprio teste, terminei a funcionalidade num tempo muito próximo ao tempo que faríamos sem teste, e o melhor é que a funcionalidade já estava testada, nem precisei abrir a tela pra testar cada situação.

Confesso que existem alguma situações que o TDD não ajuda muito, como por exemplo, num método que somente chama outro método, nesses casos, eu prefiro varrer a classe após a implementação e fazer os testes que faltaram.

Abuse do artifício dos Mock Objects, e experimente o TDD, os seus DEBUGs vão ser menos constantes e você terá a sensação de Casos de Uso concluídos de verdade.

Vocês não imaginam a sensação que tive quando rodei minha classe de testes (haviam 18 simulações testadas) e a barrinha ficou verde.

ps. uso a primeira pessoa (encontrei, tive, Gerei, etc) mas tudo isso foi feito em dupla.

JMock versus Classes Concretas

2007-12-05T12:46:00.000-08:00

O JMock (acho que o EasyMock também) precisa de uma interface para ser instanciado, mas eu precisei usar com uma Classe Concreta.

Sei que a primeira idéia é: "Porque você não cria uma interface?"

No meu caso, até poderia, mas imagine um sistema legado, onde você esteja mantendo, criar uma interface e alterar um monte de classes talvez não seja o ideal.

E isso me motivou a procurar uma solução para este problema, no site do JMock, encontrei uma referencia ao CGLib (links abaixo):

http://www.jmock.org/jmock1-cglib.html
http://www.jmock.org/mocking-classes.html

algumas horas depois...

Nas soluções acima, me parece que só funciona com o JMock 2, e aí vem a notícia mais triste que tive desde que comecei a fazer testes:

Os testes feitos com JMock 1 não rodam se eu mudar o jar do JMock para a versão 2.

Indo no site (http://www.jmock.org/versioning.html) vi isso:

2.0.0 Incompatible API changes, removes API elements deprecated by version 1.2.0.

Bem, pra quem usa JMock 1 e não quer re-fazer TODOS os seus testes, crie uma interface para a classe que será mockada.

O JMock acaba de perder 5 pontos.

EMMA - Auxiliando na cobertura de testes

2007-12-04T13:11:00.000-08:00

Caras,

o EMMA é uma ferramenta incrível para quem quer cobrir sua aplicação por testes, ela consiste em exibir relatórios de cobertura, indicando as linhas que não são cobertas, a porcentagem de cobertura, pacote e tudo mais.

COBERTURA DE TESTES COM EMMA: http://www.improveit.com.br/xp/praticas/tdd/emma

Pra quem usa eclipse, existe um plugin muito show, é o eclEMMA.

http://www.eclemma.org/

Vou mostrar um exemplo de utilização do eclEMMA.

passo 1 (escolho uma classe para ver o quanto e onde ela esta coberta):

passo 2 (seleciono a suite de testes):

Passo 3 (e o resultado de uma classe 100% coberta):

Enquanto lutava para cobrir linhas de código com meus testes, percebi que sem o eclEMMA seria muito mais difícil, por isso, indico fortemente o uso desta ferramenta.

ps. credito a descoberta do plugin ao Igo Coelho, pois não tinha ouvido falar em lugar nenhum e o mesmo me apresentou.

Passagem de parâmetros para método mockado

2007-12-04T03:08:00.001-08:00

Bem,

quando você mocka uma classe, você deve informar, no método de teste, o que o método deve fazer, então, vejamos:

classeDao.expects(once()).method("getAlgumaCoisa").
with(eq(1), eq(true)).will(returnValue(obj));

Traduzindo:

A classeDao é um mock, e neste escopo (método de teste), ele será invocado 1 única vez (expects(once())), o método que será chamado é o getAlgumaCoisa (method("getAlgumaCoisa")), quando passar os parâmetros 1 e true (with(eq(1), eq(true))), retorne um Object obj (will(returnValue(obj))).

Simples, porém me deparei com uma situação bem estranha:

O método que eu estava testando, passava como parâmetro a data atual, e não o recebia como parâmetro. Bem, o problema é o fato do método instanciar um objeto e passar como parâmetro para outro método (que iremos mockar).

Vou simplificar com um exemplo:

Na classe classeManager

o metodo fazAlgo():

//faz um blablabla
classeDao.getAlgumaCoisa(new String[]{"1", "2"});
//faz o resto do blablabla

no meu test:

Estou testando a classe classeManager

o método testFazAlgo():

se eu fizer:

classeDao.expects(once()).method("getAlgumaCoisa").
with(eq(new String[]{"1", "2"})).will(returnValue(obj));

não vai funcionar, ele vai me dizer que o método nunca foi invocado.

Pra quem já estudou um pouco de O.O. já deve ter percebido, o objeto que instanciei na classe classeManager (classeDao.getAlgumaCoisa(new String[]{"1", "2"});) é diferente do instanciado na classe de testes (classeDao.expects(once()).method("getAlgumaCoisa").
with(eq(new String[]{"1", "2"})).will(returnValue(obj));).

Então a solução é:

classeDao.expects(once()).method("getAlgumaCoisa").
with(ANYTHING).will(returnValue(obj));

o que quer dizer:

Quando eu passar "Qualquer Coisa" (with(ANYTHING)) para o método getAlgumaCoisa, retorne o obj.

Importante lembrar que a quantidade de parâmetros deve ser igual a do método "de verdade".

Quero usar mocks, uso JMock ou EasyMock?

2007-12-03T13:53:00.000-08:00

Bem, já vi defensores das duas "ferramentas", eu prefiro o JMock, acho ele muito simples e bem funcional, de qualquer forma, vou colocar aqui os links para download dos dois:

JMock: http://www.jmock.org/
EasyMock: http://www.easymock.org/

Se você quer começar com JMock: http://www.jmock.org/getting-started.html

Pra ver um caso simples das duas formas, isso pode ajudar a escolher: http://blogs.warwick.ac.uk/colinyates/entry/jmock_versus_easymock/

Aqui tem uma tabelinha com algumas diferenças: http://www.tcay.com/dev/JMockVsEasyMock.htm

O que devo saber pra começar a fazer testes?

2007-12-03T13:34:00.000-08:00

Inicialmente, aconselho estudar JUnit, que é uma ferramenta excelente para fazer testes unitários em Java e se integra com o Eclipse, Netbeans e qualquer outra IDE que mereça respeito.

Como os casos de uso evoluem e a complexidade dos testes acompanha, aconselho estudar Mock Objects.

Mocks são simulações de objetos, fazendo com que seus testes fiquem presos a um determinado escopo, por exemplo, se você esta fazendo um teste em uma classe de negócio e o método desta classe invoca um método de outra classe que faz uma consulta no banco, você deve usar um Mock para simular o objeto desta outra classe, simulando assim esta consulta, pois a consulta será testada no momento em que o teste para o seu método for criado.

Com isso você pode começar a fazer testes de seus métodos.

No site da ImproveIT existem vários materiais para estudo no assunto, vou linkar aqui em baixo dois textos bem legais:

Um pouco de TDD, é apresentado um exemplo com JUnit: http://www.improveit.com.br/xp/praticas/tdd

Mock Objects, você pode dar uma lida e ter uma boa idéia sobre o assunto: http://www.improveit.com.br/xp/praticas/tdd/mock_objects