Send us code. Get back tests. Free.

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.

Boas práticas - Parte II

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.

Fazendo testes com Ant + JUnit + JMockit

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.

JUnit4 - Suite de Testes

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

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: }