The method assertEquals(Object, Object) is ambiguous for the type TestFooBar.

This was the code that is generating this COMPILER error:

public class TestFooBar{
Map map = new HashMap();
@Before
protected void setUp() throws Exception {
map.put("r", 6.9);
}
@After
protected void tearDown() throws Exception {
}
@Test
public void testErr() {
assertEquals(6.9, map.get("r"));
}
}

The compilation error is at Line 11!!

With the autoboxing and unboxing features of JDK 1.5, 6.9 in the above example can be passed to a method whose parameter is of type double/Double/Object. And similarly a Double(caps-D) can be passed to a method that accepts Double/double/Object.

Coming to JUnit, there are two assertEquals() methods:
assertEquals(double expected, double actual)
and
assertEquals(java.lang.Object expected, java.lang.Object actual)

So, the line assertEquals(6.9, map.get(“r”)); can be mapped to either of the above two methods, leaving the compiler in ambiguity.

To clear this ambiguity, convert the parameters to most specific type.
assertEquals(6.9, (double)map.get("r"));
or
assertEquals((Double)6.9, map.get("r"));

Happy Testing

Design by Contract

Først lige et hængeparti. Jeg har endnu ikke snakket om clients og servers, hvilket er nødvendigt for at forstå dette indlæg til fulde. Følgende erdefinitionen i vores bog:

A client queries and commands a server

I eksemplet fra sidste gang med spillet Nim ville vores Pile objekt f.eks. være en server, mens vore Player ville være en client.

Med det på plads kan vi kigge på contracts. Vi siger at en “kontrakt” er en aftale mellem en server og en klient om opdeling af ansvar (se evt. sidste indlæg om design by responsibility/ansvar)

Hvis vi f.eks. skal lave en rectangle class, der kunne have en constructor:

public Rectangle (int height, int width) {
   this.height = height;
   this.width  = width;
}

I dette tilfælde kunne en klient angive negative værdier som input, hvilket ville give et absurd resultat (Vi vil f.eks. have et negativt areal). Spørgsmålet er nu: Hvis ansvar er det, at sørge for at siderne ikke bliver negative? Og hvem har ansvaret for at en areal funktion altid vil resultere i noget positivt?

Contracts! Vores kontrakter siger explicit hvem der har ansvaret for hvad. Kontrakter er en del af en klasses specifikation, og er derfor også en del af dokumentationen. Vores kontrakter er altså ikke en del af Java (eller andre sprog), hvilket betyder at vi har helt frie hænder til at specificere dem som vi vil.

Vi vil bruge ordene preconditions og postconditions om vores kontrakter. Preconditions er det en klient skal overholde når den kalder en funktion, og postconditions er det serveren overholder givet at preconditions er blevet overholdt. Vi bruger @require til at angive preconditions og @ensure til at angive postconditions. Vi bruger ligledes Javas indbyggede boolske syntaks alle de steder vi kan, således:

/**
 * A constructor for a simple rectangle class
 * @require width > 0 && height > 0
 * @ensure this.width() == width
 * @ensure this.height() == height
 * @ensure this.area() > 0
 */
Public Rectangle(int width, int height) {
   this.width  = width;
   this.height = height;
}

Her angiver this.width(), this.height(), this.area() member functions der returnerer hhv. bredden, højden og arealet. På denne måde fortæller vi klienten at hvis han ikke giver lovlige værdier for width og height kan vi ikke garantere noget som helst. Dette minder lidt om implikationspil fra den matematiske logik.

Det er vigtigt at forstå, at dette ikke handler om at en bruger kan indtaste forkert data. Det sørger vores user interface for ikke vil ske. Hvad vi er bekymrede for er at et objekt (klienten) kalder et andet objekts (serverens) metoder med ulovligt input. Hvis dette sker er det altså pga. en programmeringsfejl!

Mening med denne tilgang er, at gøre det 100% klart hvor ansvaret ligger. Vi vil naturligvis sørge for at alle fejl der kan opstå ved run-time bliver opfanget, men vi vil udføre så lidt error-checking som muligt – vi vil kun tjekke for hver mulig fejl én gang. Dette betyder at vores kode bliver hurtigere og mere overskuelig, hvilket i sidste ende leder til at den er nemmere at opdatere osv. Husk hvor meget maintainability betyder når man designer et system!

Det kan godt være at vi kan være sikre på at vores preconditions aldrig bliver overskredet hvis vi selv skriver klient-koden, men ofte vil den kode der bestemmer input til en server bestå af komplekse beregninger, hvor der nemt kan opstå fejl. Hvis vores constructor ikke gør noget i det tilfælde har den egentlig opfyldt sit job, men det kan være at vores objekt da vil bryde sin egen class invariant (en invariant er noget om klassen der altid skal være sandt. f.eks. kunne vores rektangel invariant være, at sidelængderrne aldrig må blive negative.) Vi kan derfor blive nødt til at teste input nogle gange. Vi kunne naturligvis gøre det med et if-statement (At teste input med et if-statement og lave det om til noget acceptabelt kaldes defensive programming), men det antyder, at det er forventet opførsel at vores input er forkert. Det er det absolut ikke! Hvis en precondition bliver brudt er det jo en programmeringsfejl, og vi vil ikke lade vores program køre videre. Derfor bruger vi et assert-statement således:

Public Rectangle(int width, int height) {
   assert width > 0;
   assert height > 0;
   this.width = width;
   this.height 0 height;
}

Det skal dog siges, at asserts ikke er slået til som standard, og skal slås til via. command line, hvilket betyder at vi ikke kan være sikre på at vores program vil blive kørt med dem. Dette betyder at nogle programmører prøver at undgå dem.

Det er en god øvelse at prøve at skrive preconditions og postconditions til vores klasser fra Nim-spillet.

Testing og JUnit

Når vi tester vores program snakker vi generelt om to typer testing.

• Functional testing: Også kendt som black box testing. Her er den interne struktur ukendt for testeren, og målet er at se, om systemet opfylder kundens krav. Black box testing er en videnskab i sig selv, og er ikke en del af dette kursus.
• Unit testing: Unit testing handler om at teste klasser mens de bliver udviklet. I modsætning til functional testing.

Mere specifikt

• White box testing: Test cases bliver udført på baggrund af implementationen. Vi kan f.eks. skrive en test case der tester alle branches af et if-then-else statement – Dette er hvad vi gjorde i IP.
• Gray box testing: I gray box testing skriver vi test cases før implementering af programmet. Vi skriver dem udelukkende på baggrund af vores specifikationer, og sørger for at vores kode overholder disse cases.

Det er umuligt at teste en funktion med al input. Det er også umuligt at vise om en funktion er rigtig – kun muligt at finde fejl. Vi er derfor nødt til at vælge smarte testcases.

Eksempel: Lad os sige at vi har et program for en kombinationslås. Det er en simpel lås der kun har to cifre. Man skal indtaste de to rigtige cifre i rækkefølge for at låsen åbner. Hvis koden f.eks. er 23, kunne man indtaste 4, 2, 2, 3, hvorefter låsen ville åbne, da man har indtastet 23 i den rækkefølge.

Hvilke test-cases skal vi lave til dette objekt? Først undersøger vi hvilke states vores objekt kan befinde sig i:

• Låsen er åben
• Låsen er låst
• Første ciffer er endnu ikke blevet indtastet
• Første ciffer har været indtastet

Vi laver en test-plan:

• Test initial state
  • Vi teste om låsen er åben
  • Vi kan ikke teste om kombination er sat korrekt, da vi ikke har adgang til den!
• Test at den åbner rigtigt
  • Hvis låsen allerede er åben kan vi ikke lukke den ved at taste forkerte tal ind.
  • Hvis låsen er “reset” skal vi tjekke at den korrekt kombination åbner låsen, og at en inkorrekt kombination ikke åbner den.
  • Hvis låsen er “næsten åben” skal vi sikre os at et inkorrekt andet ciffer låser låsen, at låsen forbliver “næsten åben” hvis det første ciffer tastes ind igen, og at den åbner hvis det andet ciffer tastes ind.
• Test at den låser rigtigt
  • åben, reset og låst lås bliver låst og reset efter en “close” kommando.

Vi er interesseret i at opstille såkaldte ækvivalensgrupper som reducerer antallet af tests vi skal udføre. Det betyder, at vi kan dele vores “domæne” for testdata op i ikke sammenhængende ækvivalensgrupper, og at et sæt data fra en ækvivalensgruppe er repræsentativ for hele gruppen.

Eksempelvis:

• Kombinationer hvor først ciffer er 0 (eks. 01)
• Kombinationer med to forskellige cifre (eks. 12)
• Kombinationer med to ens cifre (eks. 77)
• “Grænse-værdier” (Boundary cases) (00 og 99)

Bemærk, at både 00 og 99 har 2 ens cifre, så vi kan eliminere 77 som test case. Man kunne godt tro at en test case med 0 som første ciffer ikke burde være anderledes end en med 1 som første ciffer, men det kunne være en oplagt implementation at lade låsen starte med at have et 0 indtastet. I det tilfælde skal vi sørge for at der ikke sker noget forkert.

Dette er en masse cases og en masse arbejde, men sådan er det normalt, og det er grunden til at man skriver testcases sammen med koden og ikke først bagefter!

JUnit

JUnit er et unit testing framework til Java. Det gør det nemmer at implementere unit test plans, gør det nemmere at udføre dine tests, og giver en rapportering af hvordan testningen gik bagefter.

Junit kan ikke lave dine tests, kan ikke fortælle dig hvad du skal gøre, og det kan ikke fixe dine bugs!

Strukturen af en JUnit test ser således ud:

1. Setting up - Klargør ting, og skab objekter, variabler, osv. som skal bruges i testen
   1. @Before (før hver test funktion)
   2. @BeforeClass (en gang for alle)
2. Invoking of test function - Test funktioner er hvor tests foregår. De kan evt. kalde hjælpe funktioner (dette anbefales stærkt!)
   1. @Test
3. Tearing down - Gør rent efter test. Eksempelvis lukke brugte filer og lignende.
   1. @After
   2. @AfterClass
4. (repeat)
5. Report result

Alle tests verificeres med “assertions”. JUnit har sin egen Assert class.

En test klasse for vores kombinationslås kunne bl.a. indholde følgende:

public class CombinationLockTest {
   //Locks with the specified combinations
   private CombinationLock lock00;
   private CombinationLock lock01;
   private CombinationLock lock12;
   private CombinationLock lock99; 

   @Before
   public void setUp() {
      lock00 = new CombinationLock(00);
      lock01 = new CombinationLock(01);
      lock12 = new CombinationLock(12);
      lock99 = new CombinationLock(99);
   }

   @Test
   public void testOpenLock() {
      lock12.enter(3);
      lock12.enter(4);
      assertTrue(lock12.isOpen()); //JUnit's asserTrue
   }

   @Test
   public void testFirstDigitTwice() {
      closeLocks();
      firstDigitTwice(lock01,0,1);
      firstDigitTwice(lock12,1,2);
   }

   private void firstDigitTwice(CombinationLock lock, int first, int second) {
      lock.enter(first);
      lock.enter(first);
      assertFalse(lock.isOpen());
      lock.enter(second);
      assertTrue(lock.isOpen());
   }
}

osv.

Det er ikke altid nødvendigt med teardown, men filer og streams skal lukkes!

I have learnt some automated testing with JUnit. Junit is a java package which lets you write test suites so that you can simply run them when you program is done. It is good for software development as you can re-run the same tests again and again, and you can save some time and even avoid human generated error as missing out a particular test that happens with me over and over as I tend to forget cases.
Learning JUnit is extremely easy if you have some Java knowledge. However I noted that the official website has very less tutorials available and you wont find much information on the internet also (please direct me if you happen to know any good tutorial).
I grabbed “Pragmatic Unit Testing” by Andrew Hunt and Davis Thomas. This book is really helpful as it starts with the basics and goes through every details of JUnit. You can find a copy of the ebook if you search a little.

So, I have done one presentation about Test Driven Development yesterday, touching TDD concepts and also lots of concepts about Behavior Driven Development (BDD).

There are simple concepts about the test first process. You have to write a test that fails, write code to make the test pass and then refactor your code. Keep the bar green to keep the code clean, remember this.

Repeat this cycle until you don’t have anything else to test for a specific feature.

Looking at a User Story and its acceptance tests, you also have to make sure you are adding business value on every test.

Simple right?

Well, you have to practice.

A lot.

Really.

I’m not kidding.

Believe me.

By the way, don’t leave technical debt behind.

Just for information, currently I manage teams developing in Java (Web), Java (Mobile) and Delphi (Desktop/WebBroker).

Looking at Java Web, I’m starting to teach teams how to use JUnit for automated unit tests, and code coverage with Emma and EclEmma (Eclipse Plug-in).

For Java Mobile, the solution will be based on J2ME Unit and Cobertura for Java ME.

And Delphi, we are going with DUnit and Delphi Discover, a Coverage Tool for Delphi programmers.

And also looking at test automation, both Delphi and Java Web apps will use Selenium to help on automation of web processes.

Well, you can wait more articles on each of those tools and relation to Agile Development and eXtreme Programming practices.

So, remember: you are build tests for prevention of defects. With this you are also building tests to do regression testing.

Keep quality high, always.

At SwissProt, we test the UniProt website in several ways (though we still lack coverage, which is another topic). One area where testing was lacking for some time was JavaScript, which had accumulated over time to a somewhat substantial amount, about 3200 lines of code. We have Selenium tests for the site as a whole, but having unit tests for individual bits of JavaScript would have been great to make development of new code easier, and increase confidence in the code.

Many available frameworks such as JsUnit do in-browser testing. If you want to test actual UI code, that’s obviously what you need. But we have that at least partly covered with Selenium, and a problem with these tests is that they are difficult to run in an automated way, like from our ant test task. So I wanted something to easily and quickly test the UI-independent code, along with the Java code, from the command line, ant, or scripts. I also think that a standard JUnit-style test is way easier to write, but I guess that depends on what you’re used to.

Having read about Mozilla Rhino several times, a JavaScript interpreter written in Java with good integration between the two languages, I set out to see how much work it could be to write a simple test framework. As it turned out, it wasn’t much work at all, and there’s so little code that I can show all of it in this post.

Not only the helper classes, but also the tests themselves are written in Java, not JavaScript. The JS code to execute is passed around as Strings. That may not seem very nice, but it was very easy to implement and I don’t find it poses a problem. It’s limited in size and you don’t need to worry about syntax errors, as that code is what you’re testing in the first place.

Let’s look at a test first to see how it’s used, that’s the important part after all. We augmented the JS String class with a trim() method that’s supposed to behave like the one in Java. (I know that augmenting base JS classes is discouraged by Douglas Crockford, so we do it very rarely.)

We test our String.trim() with a JUnit test extending BaseJSTestCase. In the test, we give our trim() method a couple of strings to trim, and simply assert that the result is the same as the one java.lang.String.trim() gives. That allows for a concise test by looping over the input strings, although you could of course just as well assertEquals() with a string literal.

package core;

import java.util.Arrays;
import test.BaseJSTestCase;

public class StringTest
    extends BaseJSTestCase
{

    public StringTest()
        throws Exception
    {
        super("expasy/core/String.js");
    }

    public void testTrim()
        throws Exception
    {
        for (String str : Arrays.asList(new String[] {
                "foo",
                " foo ",
                "foo bar",
                " foo bar ",
                "!foo_23",
                " !foo_ 23 "}))
        {
            assertEquals(str.trim(),
                    eval.eval("\"" + str + "\".trim();", String.class));
        }
    }
}

As you can see, we specify the JS file containing the code to test in the constructor. This encourages a policy of having one test file per JS file, which makes navigating your tests straightforward.

The interaction with the JavaScript world happens via the eval.eval() call. Apparently there’s a JS evaluator somewhere. Unsurprisingly, it’s set in the parent:

package test;

import java.io.IOException;
import junit.framework.TestCase;

public abstract class BaseJSTestCase
    extends TestCase
{
    // TODO ugly
    protected static final String SCRIPTS_PREFIX = "web/scripts/";

    private String fileUnderTest;
    protected JSEvaluator eval;

    public BaseJSTestCase(String fileUnderTest)
    {
        this.fileUnderTest = SCRIPTS_PREFIX + fileUnderTest;
    }

    protected void setUp()
        throws IOException
    {
        eval = new JSEvaluator(fileUnderTest, this.getName());
    }

    protected void tearDown()
    {
        eval.close();
        eval = null;
    }
}

Finally we’re getting to the evaluator. It’s just as simple. All the magic happens in Rhino, we only provide an interface to its Context class. We’ve seen how we pass the name of the JS file to test in our test’s constructor. Here we see how, after some plumbing, it’s read into our context via evaluateReader(). The context is stateful, so it requires re-initializing in setUp() to get a fresh one for every test. The main interface for executing tests is the public T eval(String js, Class returnType) method. It evaluates the given code and casts the result to the given type T. The conversion to the correct Java type conveniently happens inside Rhino. There’s also the convenience method public void eval(String js) for executing test setup code whose return value is not interesting, for instance initializing some variables.

package test;

import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.EvaluatorException;
import org.mozilla.javascript.Scriptable;

public class JSEvaluator
{
    private Context context = Context.enter();
    private Scriptable scope;
    private String forTest;

    JSEvaluator(String filename, String forTest)
        throws IOException
    {
        this.forTest = forTest;
        context = Context.enter();

        scope = context.initStandardObjects();
        context.evaluateReader(scope,
                new FileReader(new File(filename)), filename, 1, null);
    }

    private Object evaluate(String js)
    {
        return context.evaluateString(scope, js, forTest, 1, null);
    }

    public void eval(String js)
    {
        evaluate(js);
    }

    @SuppressWarnings("unchecked")
    public  T eval(String js, Class returnType)
        throws JSEvaluatorException
    {
        try
        {
            return (T) Context.jsToJava(evaluate(js), returnType);
        }
        catch (EvaluatorException e)
        {
            throw new JSEvaluatorException(e.getScriptStackTrace());
        }
    }

    void close()
    {
        Context.exit();
    }

    @SuppressWarnings("serial")
    public class JSEvaluatorException
        extends RuntimeException
    {
        JSEvaluatorException(String info)
        {
            super(info);
        }
    }
}

That’s it, I hope it’s helpful and shows how easy it is to use Rhino in Java code.

About two years ago I blogged about using HSQLDB to unit test JPA entities. This year, Apache released a Derby version allowing you to use an in memory backend. As I use Derby in software I write, being able to run unit tests on the very same SGBD but in memory is a real gift.

For reference, here is a link to my previous post titled Unit test JPA Entities with in-memory database. What follows is just the very same method applied to Derby.

Dependencies

Here are the dependencies I added to my project with the “test” scope :

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-entitymanager</artifactId>
    <version>3.3.2.GA</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.apache.derby</groupId>
    <artifactId>derby</artifactId>
    <version>10.5.3.0</version>
    <scope>test</scope>
</dependency>

Persistence Unit

Here the interesting snippet of my META-INF/persistence.xml file :

<persistence-unit name="testPU" transaction-type="RESOURCE_LOCAL">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <class>myapp.model.entities.Group</class>
    <class>myapp.model.entities.User</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
        <property name="hibernate.connection.url" value="jdbc:derby:memory:unit-testing-jpa"/>
        <property name="hibernate.connection.driver_class" value="org.apache.derby.jdbc.EmbeddedDriver"/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.DerbyDialect"/>
        <property name="hibernate.hbm2ddl.auto" value="create"/>
        <property name="hibernate.connection.username" value=""/>
        <property name="hibernate.connection.password" value=""/>
    </properties>
</persistence-unit>

The unit test

Here is a simple complete test case :

 public class PersistenceUnitTest extends TestCase {

    private static Logger logger = Logger.getLogger(PersistenceUnitTest.class.getName());

    private EntityManagerFactory emFactory;

    private EntityManager em;

    public PersistenceUnitTest(String testName) {
        super(testName);
    }

    @Override
    protected void setUp() throws Exception {
        super.setUp();
        try {
            logger.info("Starting in-memory database for unit tests");
            Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
            DriverManager.getConnection("jdbc:derby:memory:unit-testing-jpa;create=true").close();
        } catch (Exception ex) {
            ex.printStackTrace();
            fail("Exception during database startup.");
        }
        try {
            logger.info("Building JPA EntityManager for unit tests");
            emFactory = Persistence.createEntityManagerFactory("testPU");
            em = emFactory.createEntityManager();
        } catch (Exception ex) {
            ex.printStackTrace();
            fail("Exception during JPA EntityManager instanciation.");
        }
    }

    @Override
    protected void tearDown() throws Exception {
        super.tearDown();
        logger.info("Shuting down Hibernate JPA layer.");
        if (em != null) {
            em.close();
        }
        if (emFactory != null) {
            emFactory.close();
        }
        logger.info("Stopping in-memory database.");
        try {
            DriverManager.getConnection("jdbc:derby:memory:unit-testing-jpa;shutdown=true").close();
        } catch (SQLNonTransientConnectionException ex) {
            if (ex.getErrorCode() != 45000) {
                throw ex;
            }
            // Shutdown success
        }
        VFMemoryStorageFactory.purgeDatabase(new File("unit-testing-jpa").getCanonicalPath());
    }

    public void testPersistence() {
        try {

            em.getTransaction().begin();

            User u = new User();
            u.setEmail("eskatos@yopmail.com");
            u.setFirstName("eskatos");
            u.setLastName("YOP");
            u.setOrganisation("Tagada");

            em.persist(u);
            assertTrue(em.contains(u));

            Group g = new Group();
            g1.addUser(u);

            em.persist(g);
            assertTrue(em.contains(g));

            g.removeUser(u);
            em.remove(u);
            em.merge(g);
            assertFalse(em.contains(u));

            em.getTransaction().commit();

        } catch (Exception ex) {
            em.getTransaction().rollback();
            ex.printStackTrace();
            fail("Exception during testPersistence");
        }
    }
}

Et voila, now with Derby !

Hoy voy a hablar de una herramienta que debería ser de uso común para el desarrollo. Estoy hablando de JUnit, la librería de pruebas unitarias más utilizado en entornos Java.

Las pruebas unitarias consisten en desarrollar código para probar una determinada funcionalidad de nuestra aplicación.

Vamos a ver un pequeño ejemplo. Supongamos que estamos haciendo una librería matemática que incluye una funcion para calcular el factorial de un número. Podría ser una clase parecida a la siguiente:

package org.tcymu.util;

public class MathLibrary {
	public static int factorial(int n) throws IllegalArgumentException {
		int response = 1;

		if (n < 0) {
			throw new IllegalArgumentException();
		}

		if (n > 0) {
			response = n * factorial(n - 1);
		}

		return response;
	}
}

En esta entrada voy a utilizar las facilidades que da Eclipse gracias a su integración con JUnit. Para ello en la vista package sobre la clase que queremos probar hacemos botón dereco -> “New” -> “JUnit Test Case”.

Nos aparece la siguiente ventana en la que seleccionamos “New JUnit 4 test” (tened en cuenta que JUnit 4 necesita Java 1.5 o superior).

Podemos ver que nos propone un nombre para la clase de pruebas, así como un paquete y una carpeta de fuentes (por defecto propone el mismo paquete que las fuentes, aunque podríamos elegir otro). También podemos seleccionar que nos cree los siguientes métodos de apoyo para preparar el entorno de los test o liberar recursos:

- Métodos setUp y tearDown. Los ejecuta antes de llamar a cada método de prueba en esa clase. La secuencia sería setUp, metodo1Test, tearDown, setUp, metodo2Test, tearDown.

- Métodos setUpBeforeClass y tearDownAfterClass. Estos métodos se ejecutan antes y después de todos los métodos de la clase. La secuencia sería setUpBeforeClass, metodo1Test, metodo2Test, tearDownAfterClass.

A continuación nos pide los métodos que queremos probar. En este ejemplo seleccionamos el método que queremos probar (factorial) y ninguno de los métodos de apoyo (en nuestro sencillo ejemplo no necesitamos crear ni liberar nada).

Tras finalizar y si no tenemos la librería JUnit 4 en el Build Path nos la añade. Y por último crea el esqueleto de la clase de prueba:

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		fail("Not yet implemented");
	}

}

Hay que destacar que lo que realmente convierte al método en un test que ejecutará JUnit es la anotación Java @Test, al igual que lo que marcaría a los métodos de apoyo serían anotaciones como @BeforeClass, @AfterClass, @Before y @After.

Podemos observar que el método testFactorial sólo contiene la línea fail("Not yet implemented"); , por lo que si ejecutamos el test (mediante botón derecho sobre la clase de pruebas y “Run As” -> “JUnit Test” se nos abre la vista de JUnit con el siguiente resultado:

Por tanto es hora de implementar nuestra prueba para pasar la barra al ansiado color verde. Básicamente se hacen comprobaciones de los resultados esperados frente a los recibidos mediante la clase org.junit.Assert (documentación Javadoc de JUnit).

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Assert;
import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		Assert.assertEquals(1, MathLibrary.factorial(0));
		Assert.assertTrue(1 == MathLibrary.factorial(1));
		Assert.assertEquals(24, MathLibrary.factorial(4));
		Assert.assertEquals(720, MathLibrary.factorial(6));

		boolean excepcionLanzada = false;
		try {
			MathLibrary.factorial(-1);
		} catch (IllegalArgumentException e) {
			excepcionLanzada = true;
		}
		Assert.assertTrue(excepcionLanzada);
	}

}

Vemos que utilizamos varios métodos para comprobar que se obtiene el resultado esperado. También podemos ver cómo probamos que se lanza la excepción esperada cuando el argumento no es válido (creo haber leído en algún sitio que se iba a mejorar la prueba de excepciones en próximas versiones, pero no consigo localizar la noticia).

Una vez que se ejecutan la prueba con éxito (la barrita verde) sabemos que el método funciona como nosotros esperamos. Ahora tras cualquier cambio en el código volveríamos a ejecutar JUnit para comprobar que no hemos roto nada. Esto nos da una gran seguridad a la hora de meter mano o refactorizar métodos complejos.

Por último no quisiera terminar la entrada sin nombrar un par de temas relacionados con las pruebas unitarias.

- Una buena prueba debe ser repetible (se debe de poder lanzar cuantas veces queramos sin afectar a nada). Por ello cada vez más se automatizan las pruebas en los procesos de integración continua de forma que antes de generarse una versión de una aplicación se corren todas las pruebas para dicha aplicación.

- Existe un modelo de desarrollo que promueve que primero se escriban las pruebas y después el código. Es el llamado Desarrollo Guiado por Pruebas o Test Driven Development (TDD).

Espero que os haya gustado esta pequeña introducción.

Scrum and Extreme Programming currently dominate named Agile processes. Less well known, but equally important, Agile processes include Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD)

Today’s typical Agile process, no matter what name you call it, takes the best from the buffet of Agile practices to create a typical process where:

1. Project needs or requirements are expressed in user stories placed in a backlog, and ideally written by Product owners (in Scrum), or customers (in XP) in collaboration with the development team. (Sometimes they magically appear.)
2. Developers give high-level estimates saying how long user stories will take to complete.
3. Product owners arrange user stories into incremental releases that take typically 6 weeks to 6 months.
4. Product owners choose the next stories, highest value first, for each development time-box. The stories chosen need to “fit” into the time-box based on how quickly the team can produce software.
5. At the end of each development time-box the team should have incrementally built some of the product. The team (proudly) demonstrates the finished product to product owners and other stakeholders.
6. The team adds up the development estimates for the user stories completed during the time-box. This is the velocity (from XP) that’ll be used to estimate the amount that can be completed in the next time-box.
7. The team holds a retrospective to evaluate how well they’ve done and what changes could be made to the process to allow things to go better, then the next time-boxed development cycle is planned.
8. Time-boxed development continues through to release — which is a short way of saying “rinse and repeat.”

There’s more common practices, such as daily standup meetings to synchronize the team, and burn-down charts to show development progress

Many links are laced through the essay — but here are a bunch in no particular order:

• Toyota production system
• The Poppendieks on Lean Software Development
• Software by Numbers
• David Anderson on Kanban
• Corey Ladas on Scrumban
• Arlo Belshee’s Naked Planning
• Aaron Sanders Kanban ground rules
• InfoQ article from Kenji Hiranabe on Kanban
• My simple Powerpoint presentation on Kanban

via Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit.

Pure Plurality and Majority Runoff
Borda Count System
Condorcet Technique and Schulze Method
The Schulze Method in Code
More to Evaluate

two different multi-attribute decision techniques in the June 2005 (msdn.microsoft.com/magazine/cc163785) and October 2006 (msdn.microsoft.com/magazine/cc300812) installments of the Test Run column.

Test Run: Group Determination In Software Testing.

In order for Surefire Maven plugin to recognize JUnit test classes their names must end in …Test

for example:

MyTests.java – will be ignored (even though it is annotated with @Test)

Pondering...

I’ve been looking into getting some more system-wide JUnit tests in place for hadoop, but have found a few challenges. Interesting, the fine folks working on hadoop do have for themselves some unit tests, and from the code-skimming I’ve done, they do seem to spin up embedded HDFS, JobTracker, and TaskTrackers (the job tracker being that bit of software that tracks the overall job you are executing while a task tracker handles the specifics of a particular map or reduce execution).

Back to the point at hand, I almost had the hadoo-test.jar code for the MiniMRCluster and MiniDfsCluster running perfectly except that when I submitted a job to the mini cluster I got an exception that loading the private class org.apache.hadoop.mapred.Child was not possible because the class was not found. Digging more, it seems that the class does indeed exist in the jars I’m using, specifically the hadoo-core jar, but the class loader simply will not pick it up, yet it finds other classes such as my Mapper, JobConf, etc. Very very strange. Googling hasn’t panned out and I’m not really at the point where I think I should engage MrUnit, mostly because it ships in the context of Cloudera’s hadoop code base.

Until I learn more about what the differences between vanilla hadoop and cloudera hadoop, I’ve resorted to building unit tests around my Mappers for the moment with only a few awkward tweaks to get it all working.

1. Always set the system property (not a Configuration property) hadoop.log.dir. If you do not, strange failures occur, mostly when dealing with the TaskTracker but I make it a point to be on the safe side.
2. Set the system property javax.xml.parsers.DocumentBuilderFactory to com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl if you are using hadoop config files. I have no idea how this got changed in my Maven setup, but in my unit tests I have to set this.
3. I also set in the JobConf the value fs.default.class to org.apache.hadoop.fs.RawLocalFileSystem and the value fs.default.name to file:/tmp. I’m not convinced both of these are absolutely necessary for me to read my input files off disk out of src/test/resources, but there it is.

After all that, I can simply call the mapper’s map method is measure the results. No cluster needed.

Following part 1 and 2 which covered the JUnit test class creation and the coverage evaluation by Cobertura, we will add in part 3 another dimension: Automation. So far we run the tests manually, but we want to achieve a continuous integration and test environment.

Part 3 (Cobertura and Hudson)

Preparation:

• Part 1 (link)
• Part 2 (link)
• Download Hudson (website)
• Running Subversion with the project uploaded
  

Tutorial:

• Download and install Hudson
  Hudson can run standalone (easier for testing, trialing and experimenting) or as a deployed application on an application server.
  Once you downloaded it, just navigate with a terminal session (aka Dos-Box) and start it with “java -jar hudson.war“
  You will get something like this:
  

  Hudson

  I will not go into any details of how to configure Hudson, but jump straight to our project. Maybe in another tutorial I will explain the basic setup of Hudson, but it so simple and the documentation is so good, it is easy for your to do the necessary settings.

• Tweak our Netbeans Project
  As per standard setting when creating a new Netbeans project, the libraries are not kept in the project folder, but copied for deployment only. But Hudson need to access these libraries, one approach to solve this, is to keep the library files in the project folder.
  

  Netbeans Project (Standard Folder)

  

  Local Libraries

  Open the project in Netbeans and open the project properties (right click project name).  In the libraries section you just click Browse and Next.

  

  Libraries

  Once this is done the libraries are kept locally in your project folder.
  Now comes the interesting part, you remember the recommendation from the previous part of the tutorial saying you should modify only the build.xml file ?

  

  build-impl.xml

  Netbeans needs to recreate its build file after our changes. So either we change it for Netbeans and select cancel (not knowing what changes need to be done) or we redo our changes or keep them finally in our own build.xml file.

• Create new Job in Hudson
  Your Hudson is running and you can access it via http://localhost:8080 (assuming you run it as standalone on your local machine)
  You see a mainpage like this
  

  Hudson Portal

  Create new Hudson Job (Build a free-style software project)

  

  Create new Hudson Job

  Configuration of new Job in Hudson

  

  New Hudson Job

  The following parts of the configuration page are interesting for us
  SVN repository

  

  SVN

  Invoke Ant (please note it needs to be downloaded and configured first in the main Hudson configuration)

  

  Invoke Ant

  Trigger JUnit Report Creation (default path is usually **/build/test/results/*.xml)

  

  JUnit Report

  Trigger Corbertura Report (default path is **/build/report/cobertura/coverage.xml)

  

  Trigger Cobertura Report

  All other configuration we dont need right now (I added the email function to drop me an email if the build is broken).

• Trigger the first Build
  

  Job Screen (no build yet)

  

  First Build

  If everything is running fine we should have result like this (inclusive all Ant and JUnit log output)

  ...
  BUILD SUCCESSFUL
  Total time: 10 seconds
  Recording test results
  Publishing Cobertura coverage report...
  Publishing Cobertura coverage results...
  Finished: SUCCESS
  

  Starting with the second build we will see a graph giving us tendencies over the last builds.
  In our sample project we have covered 100% of the classes but only 50% of the lines.

  

  Build Overview

  Test Code 50%
  @Test
  public void testApp() {
  TestMe tst = new TestMe();
  int res = tst.doSomething(3);
  assertEquals(“Correct value”, 0, res);

  //res = tst.doSomething(6);
  //assertEquals(“Correct value”, 2, res);

  //res = tst.doSomething(11);
  //assertEquals(“Correct value”, -1, res);
  }

  Lets re-insert the full test code and we get this after our next build:

  

  Build Overview

Where to go from here:

• Explore all the features of Hudson, eg. Javadoc feature, trigger other builds and use fingerprints.
• Make Hudson production ready by deploying it on an application server such as Glassfish and securing it with logins,..

What else could I plug-in or do:

• There is a huge number of plugins available that help you to integrate with all kind of tools and frameworks.
• You can try the Netbeans Hudson feature (version 6.7 and higher)
• You could try using the Firefox plugin to constantly see the build status.

Following part 1 which covered the class and JUnit class creation and ended in a suspected successful test.

Part 1 (covering Cobertura setup and execution)

Preparation:

• Part 1 (link)
• Download Cobertura (website)
  

Tutorial:

• Extract the Cobertura file (named cobertura-1.9.3-bin.zip, 1.9.3 is the actual version at the time of creation of this tutorial)
  You will find 4 library files (jars) that you need to copy somewhere. I copied them into my ANT folder under Netbeans for this tutorial, but I would recommend to copy the files into the lib folder of your project.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Add the libraries to our project
  Project Properties|Libraries|Run Test folder
  As I remarked before, here I point to a relative path outside my project folder which is not good practice.
  

  Cobertura Tutorial

• Modify the Netbeans project properties file
  There is currently no Cobertura plugin available for Netbeans (at least I am not aware of one, except one on project kenai server, but it’s not implemented yet)
  Open the file explorer view of our project and opent he file project.properties (which is created by Netbeans and updated when we change project settings). For serious projects I recommend to always make a copy before manually changing its content.
  We add 3 lines for our instrumented class files.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

  # FOR COBERTURA
  build.instrumented.dir=${build.dir}/instrumented
  build.report.dir=${build.dir}/report
  build.report.cobertura.dir=${build.report.dir}/cobertura
  

• Modify the Ant build script
  Ant can do a lot, Maven maybe more. I am not an Ant expert, but at least I could bend  my brain around it and figure out how it works. So far I was the lazy Netbeans user “what is ant?”
  I will not explain Ant (curious readers can proceed to ant.apache.org), but you should understand the concept of tasks and dependencies.
  Netbeans creates to build files: a build.xml in your project root and a build-impl.xml in the nbproject subfolder. You are advised to add ant tasks in the build.xml file, the other file is maintained by Netbeans.
  First we need to tell ant to create the instrumented class files (Cobertura add some stuff to each line of our byte code). The instrumented bytecode is kept separately and does not affect our production classes.
  open the build.xml file, it should be empty except some header (that also imports the other buildfile) and some remarks explaining how it works. Right at the end (before the </project>)  we add this

  <property environment="env"/>
  <taskdef classpath="cobertura.jar" resource="tasks.properties"/>
  <target name="-pre-compile-test">
   <delete dir="${build.instrumented.dir}" />
   <delete dir="${build.report.cobertura.dir}" />
   <mkdir dir="${build.instrumented.dir}" />
   <mkdir dir="${build.report.cobertura.dir}" />
   <cobertura-instrument todir="${build.instrumented.dir}">
   <fileset dir="${build.classes.dir}">
   <include name="**/*.class"/>
   </fileset>
   </cobertura-instrument>
  </target>
  

  It is not a new task (there are no dependencies here) but it overrides the task with same name in the build-impl.xml file.

  <    <target name="-post-compile-test">
   <!-- Empty placeholder for easier customization. -->
   <!-- You can override this target in the ../build.xml file. -->
   </target>
  

  Every time we test the whole project this task is called and will create the instrumented class files for us.

• Modify the class path for test execution
  This is the part which I didnt figure as fast. The cobertura result was created and always showed 0% coverage. You need to tell Netbeans/Ant to use the instrumented classes for the test not the regular ones in your build folder.
  

  Cobertura Tutorial

  Open the project.properties file again and make sure to add the line ${build.instrumented.dir}:\ before your regular build path.
  Note the entries with ${file.reference.asm-3.0.jar}:\ were added by Netbeans when we added the Cobertura libraries. You could adjust the classpath order using the project properties as well.

  javac.test.classpath=\
   ${javac.classpath}:\
   ${build.instrumented.dir}:\
   ${build.classes.dir}:\
   ${libs.junit_4.classpath}
  ..
  run.test.classpath=\
   ${javac.test.classpath}:\
   ${build.instrumented.dir}:\
   ${build.test.classes.dir}:\
   ${file.reference.asm-3.0.jar}:\
   ${file.reference.asm-tree-3.0.jar}:\
   ${file.reference.cobertura.jar}:\
   ${file.reference.jakarta-oro-2.0.8.jar}:\
   ${file.reference.log4j-1.2.9.jar}
  

  Executing the test for our project now will use the instrumented classes and creates a coverage result files for us (cobertura.ser, NO, you cant open the file in the editor)

• Modify the build script to convert the result file in human readable websites.
  I do this (breaking the previous rule) in the build-impl.xml file, but it would be fairly easy to migrate this to “our” build.xml file.
  Look for this section

   <target depends="init,compile-test,-pre-test-run,-do-test-run" if="have.tests" name="-post-test-run">
   <fail if="tests.failed">Some tests failed; see details above.</fail>
   </target>
  

  and ammend it:

   <target depends="init,compile-test,-pre-test-run,-do-test-run" if="have.tests" name="-post-test-run">
   <fail if="tests.failed">Some tests failed; see details above.</fail>
   <!-- You can disable the html portion if you are using the hudson plugin and rely on the xml -->
   <cobertura-report format="html" srcdir="${src.dir}" destdir="${build.report.cobertura.dir}"/>
   <!-- Used by the hudson plug-in -->
   <cobertura-report format="xml" srcdir="${src.dir}" destdir="${build.report.cobertura.dir}"/>
   <delete file="cobertura.ser" />
   </target>
  

• Execute the tests and enjoy the results
  You trigger the test for the whole project and your output will be like this

  init:
  deps-jar:
  compile:
  Deleting directory /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Deleting directory /home/sven/NetBeansProjects/CoberturaDemo/build/report/cobertura
  Created dir: /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Created dir: /home/sven/NetBeansProjects/CoberturaDemo/build/report/cobertura
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Instrumenting 1 file to /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Instrumenting 1 file to /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Cobertura: Saved information on 1 classes.
  Cobertura: Saved information on 1 classes.
  Instrument time: 77ms
  Instrument time: 77ms
  compile-test:
  Testsuite: demo.TestMeTest
  Smaller than 5
  Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.099 sec
  
  ------------- Standard Output ---------------
  Smaller than 5
  ------------- ---------------- ---------------
  Cobertura: Loaded information on 1 classes.
  Cobertura: Saved information on 1 classes.
  test-report:
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura: Loaded information on 1 classes.
  Cobertura: Loaded information on 1 classes.
  Report time: 251ms
  Report time: 251ms
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura: Loaded information on 1 classes.
  Cobertura: Loaded information on 1 classes.
  Report time: 107ms
  Report time: 107ms
  Deleting: /home/sven/NetBeansProjects/CoberturaDemo/cobertura.ser
  test:
  BUILD SUCCESSFUL (total time: 3 seconds)
  

  You still will end up seeing the JUnit test result pane with “test passed”, but lets go to the report folder in our project and open the index.html file (Ignore the coverage.xml file because it is used by theHudson plugin that we will discuss in part 3)

  

  Coberture Tutorial

  Ops, there is still something in red !

  

  Corbertura Tutorial

  Cobertura tells us exactly which part of our method was never touched by our tests !

  

  Corbertura Tutorial

• Increase the code coverage|
  Lets go back to our project and add test cases

  ..
   @Test
   public void testApp() {
   TestMe tst = new TestMe();
   int res = tst.doSomething(3);
   assertEquals("Correct value", 0, res);
  
   res = tst.doSomething(6);
   assertEquals("Correct value", 2, res);
  
   res = tst.doSomething(11);
   assertEquals("Correct value", -1, res);
   }
  ..
  

  and test again

  

  Cobertura Tutorial

  Voila ! All lines and branches are covered. 100% (Find my remark later)…GREEN all over.

  

  Cobertura Tutorial

Resume:
I love this tool. Thanks for creating it. I cant add quality to the source (it is open source) but at least I could create this tutorial for more folks to get started. Use Corbertura !
I will try Corbertura with Hudson in the next part and also try it on web applications.

2 more remark:
Dont let fool yourself in the assumptions that covering all lines in your codebase really reflects a complete test, you still need to test the business logic of your application against various use cases !
In reality 100% coder coverage is not realistic. The complexity explodes with combination of for/while loops combined with if statements, and also platform dependendant or very exceptional parts might not be possible to be covered. But try your best
References:
I could not get the tutorial running without using this pre-existing fragments/snippets/ideas and websites

• http://cobertura.sourceforge.net
• http://ant.apache.org/
• http://wiki.netbeans.org/CoberturaAnt
• http://www.devdaily.com/blog/post/java/sample-cobertura-ant-build-script/
• http://www.ibm.com/developerworks/java/library/j-cobertura/
• http://weblogs.java.net/blog/fabriziogiudici/archive/2007/02/automating_test.html
• http://cobertura.sourceforge.net/mavenCobertura.html
• http://kenai.com/projects/nbcobertura

Update (2009-09-25):
There is a problem with the path of Cobertura. The above tutorial only works because the 4 jar files are in the ant folder, which is in the path !  I realized this after testing the project in a different environment.

I believe strongly in testing. I saw companies and products without any automatic test frameworks and the slightest change to the codebase (often in the urgent ‘we-need-to-fix-it-now-and-give-to-the-customer-in-1hr’ mode) made parts of the product or modules prone to crashes because no one could test the changes against the complete application. In my current endevour to create a new product we embrace testing, though we dont practice TDD (test-driven-development), but at least we maximize the amount of automatic testing with tools/frameworks like Netbeans, Hudson, Cobertura and others. If you dont practice TDD, how can you judge how much of your codebase is really tested, even you assume all you business testcases are covered ?

The other day Code Coverage crossed my way (Thanks Chris!). Eager to find out how to “do it” or to “use it” I found a few tools suitable for the Netbeans environment. It actually drilled down to only one tool: Cobertura. It fits exactly into our landscape using Netbeans and Hudson and it is opensource.
To get started with Cobertura you should be familiar (a bit) with Netbeans, JUnit and Ant. The Cobertura website offers sufficient reference for all functions and introduction to get you started. But what I missed is a tutorial the start from the scratch using Netbeans and Cobertura. I found 3 references (I will add them at the end,) which are not complete or just not working for me), so let me share the most basic getting-started steps with you.
Please note: This is how I get started, it might not be complete, foolproof or even correct in all details. Please feel free to comment, correct or give other feedback !

Part 1 (covering project creation and JUnit test)

Preparation:

• You have basic knowledge of Java and Netbeans.
• Netbeans 6.5.1 (I guess older or newer versions work also)

Tutorial:

• Create a new Java Project using the new project wizard of Netbeans
  Call it CoberturaDemo. Deselect create Main class.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Create a new class
  Name it TestMe in the package demo
  

  Cobertura Tutorial

• Add some basic functionality that we can test later.
  It is only a function that checks an int value if smaller than 5 or even in 2 if {} statements and returns 0 or 2. Useless function but we have something to “code-cover” !
  

  Cobertura Tutorial

  package demo;
  
  public class TestMe {
  
   public int doSomething(int i) {
   if (i < 5) {
   System.out.println("Smaller than 5");
   return 0;
   }
  
   if (i % 2 == 0) {
   System.out.println("Even number");
   return 2;
   }
  
   return -1;
   }
  }
  

• Add JUnit Test Skeleton for our class
  By right-click the TestMe.java file in the demo package. Tools | Create JUnit test.
  For this tutorial we leave the defaults since we are not discussing them.
  Netbeans will create a test skeleton file for you (TestMeTest.java)..
  Comment: TestMe.java was not a good name choice. All Junit Test files are called {yourClassName}Test.java.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Create a real JUnit test
  The skeleton does NOTHING for us, so we need to add a test. You believe Netbeans creates testcases for you ?
  We create a simple test, only 1 for now, that throws a value at the method and checks for the expected value.
  

  Cobertura Tutorial

  package demo;
  
  import org.junit.Test;
  import static org.junit.Assert.*;
  
  public class TestMeTest {
  
   public TestMeTest() {
   }
  
   @Test
   public void testApp() {
   TestMe tst = new TestMe();
   int res = tst.doSomething(3);
   assertEquals("Correct value", 0, res);
   }
  }
  

• Execute JUnit test
  We are already at out first testing stage ! Note that java class cannot be run, but the JUnit test.
  Right click on the project (project explorer) and select Test.
  You should get something like this:
  

  Cobertura Tutorial

  You can experiment, aka break it, by changing the expected value to 99 and execute test again.

Resume Part 1:
We crceate a Java class and a JUnit test class for it. We executed the test and saw “test passed”. We could belive “my class is tested ! lets move on..“.
NO ! Half the code is NOT tested and JUnit wont tell us either ! Of course it is obvious for this most simple sample, but just think about your projects that are usually a bit more complex. Would you “see” it, if not everything is covered ? Certainly NOT. So we need a tool to tell us.

Part 2 will introduce Cobertura as our new magic wizard to our demo project.
Part 3 will cover Hudson and the Cobertura plugin for Hudson.

Stay tuned.

A la hora de ir haciendo las muy útiles pruebas unitarias para ir verificando que el código funciona correctamente, existen múltiples posibilidades para tratar este tema.

Por un lado están las pruebas de caja negra (ejecución de tests, digamos) y por el otro, las de caja blanca (cubrir todas las líneas de código implementadas).

JUnit

Con esta herramienta realizamos las pruebas. Tan simple como seguir el manual de la propia página o cookbok.

ECLEmma

Gracias al plugin para Eclipse, se consigue averiguar la cobertura de código que se realiza con los tests. De esta forma, se consiguen unas pruebas más completas.

Creando el script en Ant

Al añadir a Ant las líneas adecuadas para la ejecución de pruebas de manera automática, se ha optado por usar Cobertura. De esta manera, se automatiza el proceso de cobertura fácilmente.

El proceso consiste en añadir en Ant las librerías de cobertura y después, especificar varias opciones. Todo este proceso se explica adecuadamente, a mi parecer, en la propia página de Cobertura.

En nuestro caso, esta parte quedaría así:

<path id="cobertura.classpath">

   <fileset dir="${cobertura.dir}">

   <include name="cobertura.jar" />

   <include name="lib/**/*.jar" />

   </fileset>

 </path>

Luego entre las opciones a especificar:

<!-- =================================

	target: instrument

 ================================= -->

	<target name="instrument"

		description="Crea las clases de instrumentación para generar la cobertura"

		depends="init.instrument">

		

		<!-- Se eliminan los ficheros de ejecuciones anteriores -->

		<delete file="cobertura.ser" />

		<delete dir="${build.instrumented.dir}" />

		

		<cobertura-instrument todir="${build.instrumented.dir}">

	    	<fileset dir="${build.dir}/classes">

	        	<include name="**/*.class" />

	    	    <exclude name="**/*Test.class" />

		    </fileset>

		</cobertura-instrument>

	</target>

	

<!-- =================================

	target: test

 ================================= -->

	<target name="test" depends="init,compile,instrument" description="Ejecuta las pruebas de cobertura. Para ello es necesario

		tener ejecutando el motor de MySQL y Matlab.">

		<junit fork="yes" dir="${basedir}" failureProperty="test.failed">

	    	<classpath location="${build.instrumented.dir}"/>

	    	<classpath location="${build.classes.dir}"/>

			<classpath location="${build.dir}"/>

			<classpath refid="sql.classpath" />

			

			<formatter type="xml"/>

			<classpath refid="cobertura.classpath" />

			

			<formatter type="xml" />

			<test name="${testcase}" todir="${report.junit.dir}" if="testcase"/>

		

			<batchtest todir="${junit.xml.dir}" unless="testcase">

				<fileset dir="${test.dir}">

					<include name="**/*.java"/>

				</fileset>

			</batchtest>

		</junit>

		

		<junitreport todir="${junit.xml.dir}">

			<fileset dir="${junit.xml.dir}">

				<include name="TEST-*.xml"/>

			</fileset>

			<report format="frames" todir="${junit.html.dir}" />

		</junitreport>

	</target>

	

<!-- =================================

	target: coverage-check

 ================================= -->

	<target name="coverage-check" depends="" description="Comprueba que las pruebas de cobertura están en un intervalo especificado">

			<cobertura-check branchrate="35" totallinerate="100" />

	</target>

	

<!-- =================================

	target: coverage-report

 ================================= -->

	<target name="coverage-report" depends="test" description="Crea un informe html con la cobertura de las pruebas">

		<cobertura-report destdir="${cobertura.html.dir}">

		   <fileset dir="${src.dir}">

		       <include name="**/*.java" />

		       <exclude name="**/*Stub.java" />

		   </fileset>

		</cobertura-report>

	</target>

	

<!-- =================================

	target: coverage-report-xml

 ================================= -->

	<target name="coverage-report-xml" depends="coverage-report" description="Crea un informe xml con la cobertura de las pruebas">

	    <cobertura-report format="xml" srcdir="${src.dir}" destdir="${cobertura.xml.dir}"/>

	</target>

I started out intending to write some scala examples against the twitter API, however I soon discovered I needed OAuth first. Given that I use OAuth all the time at work I figured I could probably do with learning about it first-hand, while learning scala.

org.junit.rules._

I chose to test drive it with JUnit 4.7 and NetBeans.

NetBeans works almost immediately with scala, and has support for project templates etc — even scala JUnit fixtures.

JUnit mostly works, though rules don’t and neither do some matchers. Even though rules don’t work, I have included it anyway because I have the t-shirt.

You can find the project on github.

Important abstractions

1. SignatureBaseString.
   1. Characterized by three ampersand-separated segments: verb, uri, parameters.
   2. URL Encoding must conform to RFC 3986, and the following characters should are consider unreserved so should not be encoded:
      ALPHA, DIGIT, ‘-’, ‘.’, ‘_’, ‘~’
2. Signature.
   1. Signature is a keyed-Hash Message Authentication Code (HMAC).
   2. Consumer secret required part of HMAC secret key.
   3. Token secret is optionally included in HMAC secret key:
      (consumer_secret, token_secret) => uri_encoded_consumer_secret&[uri_encoded_token_secret]
3. OAuthCredential. Represents the secret key(s) used to create the HMAC signature. OAuth requires a consumer credential, and optionally a token credential, representing the end user.

Now that these core concepts are complete, I am working on high-level policy, like classes for generating signed URLs and authorization headers.

Notes

JUnit — expecting exceptions in scala

Assuming JUnit 4.x, a test can expect an exception using the test annotation:

Java:

@Test(expected=IllegalArgumentException.class)
    public void ExampleThrowsException(){
        throw new IllegalArgumentException();
    }

This needs to be modified for scala:

Scala:

@Test { val expected=classOf[IllegalArgumentException] }
    def ExampleThrowsException {
        throw new IllegalArgumentException
    }

The reason for it is outlined here in the Java annotations section on named parameters.

Here is the documentation for scala annotations. Seealso: the documentation for scala 2.7.3 (includes dbc).

Closures and return

The return statement immediately returns from the current method, even if you’re within a closure. Omit return in this case — return is optional anyway.

When to use semicolon line terminator

Never — apart from:

• When a method returns Unit (equivalent to void) and you aren’t using return keyword. [TBD: Add example].

How to use blocks

var count = 1
times(2) { println("Printed " + count + " times")}
protected def times(count : Int)(block : => Unit) = {
    1.to(count).foreach((_) => block)
}

References

• Scala oauth lib (Github).
• OAuth specification.
• Scala 2.7.3 documentation.
• OAuth ruby gem.
• OAuth test client.

ALPHA, DIGIT, '-', '.', '_', '~'

Neste post irei demonstrar a utilização do componente rich:editor que faz parte da biblioteca de componentes RichFaces.

O rich:editor é um componente usado para a criação de um editor em páginas. Seu uso é relativamente simples e o resultado é impressionante.

A aplicação consiste num cadastro de Rascunhos onde o usuário poderá cadastrar e remover seus rascunhos de uma forma prática e simples. Para gerenciar as sessões/transações do Hibernate criei um serlvet filter Open Session In View fazendo papel de um interceptador, que será executado a cada request e response.

Utilizarei Tomcat, Hibernate e MySQL para a persistência de dados e disponilizarei o projeto para download.

Estrutura do projeto

Versões utilizadas

• Eclipse 3.4.1
• JDK 1.6
• Tomcat 6.0.18
• MyFaces 1.2.5
• RichFaces 3.3.1
• Hibernate Annotations 3.4.0
• Hibernate 3.3.1
• MySQL 5
• MySQL Query Browser 1.2

Códigos

Rascunho.java:

package br.com.serjaum.modelo;

@Entity
@Table(name="rascunho")
public class Rascunho implements Serializable{

 private static final long serialVersionUID = -6142163109498247473L;

 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 @Column(name="RASCUNHO_ID")
 private Long id;

 @Column(name="titulo")
 private String titulo;

 @Temporal(TemporalType.DATE)
 @Column(name="data")
 private Date data = new Date();    

 @Lob
 @Column(name="conteudo")
 private String conteudo;

...
}

RascunhoMB.java:

package br.com.serjaum.mb;

public class RascunhoMB implements Serializable {

 private static final long serialVersionUID = -7138652046367400871L;

 private Long id;

 private Rascunho rascunho = new Rascunho();

 public RascunhoMB(){
 System.out.println(" >>>>>>>>>>>>>>>>>>>> Construtor do RASCUNHO_MB <<<<<<<<<<<<<<<<<<");

 if(this.rascunho == null){
 this.rascunho = new Rascunho();
 }
 }

 public String save(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 rascunhoDAO.save(this.rascunho);

 this.rascunho = new Rascunho();
 return "toIndex";
 }

 public String delete(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 this.rascunho = rascunhoDAO.load(this.id);
 rascunhoDAO.delete(this.rascunho);
 this.rascunho = new Rascunho(); 

 return "removeSucesso";
 }

 public String merge(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);
 rascunhoDAO.merge(this.rascunho);
 this.rascunho = new Rascunho(); 

 return "atualizaSucesso";
 }

 public String load(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 this.rascunho = rascunhoDAO.load(this.id);

 return "pesquisaSucesso";
 }

 public String pesquisaByTitulo(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 this.rascunho = rascunhoDAO.pesquisaRascunhoByTitulo(this.rascunho.getTitulo());

 return "pesquisaByTituloSucesso";
 }

 public String exibeRascunho(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 this.rascunho = rascunhoDAO.load(this.id);

 return "toRascunho";
 }

 public List<Rascunho> getRascunhos(){
 Session session = HibernateUtil.currentSession();
 RascunhoDAO rascunhoDAO = new RascunhoDAO(session, Rascunho.class);

 return rascunhoDAO.list();
 }

 public Long getId() {
 return id;
 }

 public void setId(Long id) {
 this.id = id;
 }

 public Rascunho getRascunho() {
 return rascunho;
 }

 public void setRascunho(Rascunho rascunho) {
 this.rascunho = rascunho;
 }
}

cadastraRascunho.xhtml:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:a4j="http://richfaces.org/a4j"
 xmlns:rich="http://richfaces.org/rich">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
 </head>

 <a4j:keepAlive beanName="rascunhoMB" />

 <ui:composition template="/template/template.xhtml">
 <ui:define name="corpo">
 <h:form>
 <rich:messages />

 <fieldset>
 <legend>Rascunho</legend>
 <h:panelGrid columns="1">
 <h:outputLabel for="titulo" value="Título "/>
 <h:inputText id="titulo" value="#{rascunhoMB.rascunho.titulo }" required="true" requiredMessage="Preencha o Título do Rascunho" styleClass="edit" size="35" />

 <h:outputLabel for="conteudo" value="Conteúdo "  />
 <rich:editor id="conteudo" theme="advanced" value="#{rascunhoMB.rascunho.conteudo}" required="true" requiredMessage="Preencha o Conteúdo do Rascunho" height="300" width="700"/>
 </h:panelGrid>

 <a4j:commandButton value="Salvar " action="#{rascunhoMB.save}" styleClass="botoes"/>
 <h:commandButton value="Voltar " action="toIndex" immediate="true" styleClass="botoes"/>
 </fieldset>
 </h:form>
 </ui:define>
 </ui:composition>
</html>

rascunho.xhtml:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:a4j="http://richfaces.org/a4j"
 xmlns:rich="http://richfaces.org/rich">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
 </head>

 <a4j:keepAlive beanName="rascunhoMB" />

 <ui:composition template="/template/template.xhtml">
 <ui:define name="corpo">
 <h:form>
 <rich:messages />

 <fieldset>
 <legend>Rascunho</legend>
 <h:panelGrid columns="2">
 <h:outputLabel for="titulo" value="Título "  />
 <h:outputLabel id="titulo" readonly="true" value="#{rascunhoMB.rascunho.titulo}" style=" width : 254px;"/>

 <h:outputLabel for="data" value="Data "  />
 <h:outputLabel id="data" readonly="true" value="#{rascunhoMB.rascunho.data}" style=" width : 254px;">
 <f:convertDateTime pattern="dd/MM/yyyy" />
 </h:outputLabel>
 </h:panelGrid>    

 <h:panelGrid columns="1">
 <rich:editor theme="advanced" autoResize="true" value="#{rascunhoMB.rascunho.conteudo}" height="300" width="822" readonly="true"/>
 </h:panelGrid>                

 <a4j:commandButton value="Salvar " action="#{rascunhoMB.save}" styleClass="botoes"/>
 <h:commandButton value="Voltar " action="toGerenciaRascunhos" immediate="true" styleClass="botoes"/>
 </fieldset>
 </h:form>
 </ui:define>
 </ui:composition>
</html>

Importando o projeto

1. Baixe o projeto completo >>aqui<<;
2. Descompacte o projeto no seu workspace;
3. No Eclipse vá em: File –> Import –> General – Existing Projects into Workspace –> Next –> Selecione o projeto descompactado no workspace –> Finish.

Criando o banco de dados

1. Com o MySQL instalado e configurado com usuário: root e senha: root crie um novo schema com o nome de jsf.
2. Execute a classe br.com.serjaum.util.GerarTabelas.java. Essa classe criará as tabelas que foram mapeadas no arquivo hibernate.cfg.xml, no caso a classe Rascunho terá uma tabela correspondente com o nome de rascunho no nosso banco de dados.

Resultado

Até o próximo post!

Just the other day I was wondering how DBUnit was doing. As a former consultant I used to use DBUnit along with various JUnit extensions on a regular basis.

Given that Eclipse has moved on, JUnit has moved on and DBUnit has moved on I thought I would present a straightforward example of how to use DBUnit with JUnit 4.0 and Eclipse.

Not that much has changed therefore there is not going to be a lot of hand holding here.

Assumptions

Eclipse 3.5
JUnit 4.0 – included with Eclipse
DBUnit 2.4.5
SLF4J 1.5.8 – DBUnit needs this
HSQL DB 1.8.0

I implemented this example on Kubuntu 9.10, if that makes any difference.

If you are new to Eclipse then just download any version that seems reasonable as long as it includes a Java development environment.

The Easy Part

Make sure all of the above software is available somewhere on your machine. If not, install all the software in your favorite places.

Start Eclipse.

The Short Version

1. Start your database
2. Create a Java Project
3. Add DBUnit to your classpath
4. Write and run a database test
   • Create initial and expected dataset files
   • Extend DBTestCase (inheritance) or use a JUnit class (composition)
   • Implement your test methods

The Longer Version

Start your database

I don’t have a database to run so I downloaded and installed HSQL. To run the HSQL server, which I prefer in examples, open a command window, go to the HSQL folder and run:

java -cp lib/hsqldb.jar org.hsqldb.Server -database.0 file:hiddenclause -dbname.0 xdb

In this case the database name is xdb with the database files named hiddenclause.*. Call your files whatever. I will add test data later.

My Eclipse default configuration includes:
Source folder name: src
Output folder name: classes

Default execution environment: JavaSE-1.6

Create a Java Project

Create a Java Project named DBUnitExample. ‘Nuff said.

Add DBUnit to your classpath

Once the project appears in the Package Explorer, right click on the project name and select Properties –> Java Build Path –> Libraries. Click Add External JARs and add the DBUnit JAR file, in this case dbunit-2.4.5.jar, to the list of libraries in the classpath. Yes, you could also have done this when you first created the project.

Add:
- slf4j-api-1.5.8.jar
- slf4j-simple-1.5.8.jar
- hsqldb.jar
to the classpath as well.

Click OK to close the Properties window.

Write and run a database test

Add Test Data

As running a test on a fresh database is a little difficult start the HSQL Database Manager from another shell (in the HSQL directory):

java -cp lib/hsqldb.jar org.hsqldb.util.DatabaseManager

In the Connect window enter:
Setting Name: hiddenclause example
Type: HSQL Database Engine Server
Driver: org.hsqldb.jdbcDriver
URL: jdbc:hsqldb:hsql://localhost/xdb
User: sa
Password: [leave blank]

Click OK.

Almost done. Select Options –> Insert Test Data. Now we have 4 tables worth of data to test with. Run a delete on the CUSTOMER table so that is is empty.

Close the Database Manager.

Write a Database Test

The steps for writing a DBUnit test are:
1. Create initial and expected dataset files
2. Extend DBTestCase (inheritance) or use a JUnit class (composition)
3. Implement your test methods

Once you get comfortable with that the additional steps are:
1. Create initial and expected dataset files
2. Extend DBTestCase (inheritance) or use a JUnit class (composition)
3. Implement getSetUpOperation() and getTearDownOperation() (optional)
4. Override setUpDatabaseConfig() (optional)
5. Implement your test methods

We’ll just do the first one using the test data created by HSQL.

Create initial and expected dataset files

The DBUnit dataset can come from anywhere (files, databases, spreadsheets, etc.). Where the data comes from is hidden behind the class that implements IDataSet. For this example, we will use XML datasets.

Here is the initial dataset file:
customer-init.xml

<?xml version="1.0" encoding="UTF-8"?>
<dataset.
    <CUSTOMER />
</dataset>

Here is the expected dataset (what we expect to find in the database after executing some code):

<?xml version="1.0" encoding="UTF-8"?>
<dataset>
     <CUSTOMER ID="1"
               FIRSTNAME="John"
               LASTNAME="Smith"
               STREET="1 Main Street"
               CITY="Anycity" />
</dataset>

Extend DBTestCase (inheritance) or use a JUnit class (composition)

The first version of CustomerTest will inherit from the DBUnit class DBTestCase. That is the recommended way of creating a DBUnit test. It uses the JUnit 3.8.2 classes which still works even with the JUnit 4.0 JAR file.

public class CustomerTest extends DBTestCase {
...
    @Override
    protected IDataSet getDataSet() throws Exception {
        ...
    }
}

The getDataSet() method is called to initialize the database before the test. Consider it part of your setup logic. Let’s load the initialization dataset.

    @Override
    protected IDataSet getDataSet() throws Exception {
        return new FlatXmlDataSet(
                 new FileInputStream("customer-init.xml"));
    }

There are a number of properties that need to be set prior to DBUnit doing its magic. You can set those properties in the constructor:

    public CustomerTest(String name) {
        super(name);
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS,
          "org.hsqldb.jdbcDriver");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL,
          "jdbc:hsqldb:hsql://localhost/xdb");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME,
          "sa");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD,
          "");

        _customerFactory = CustomerFactory.getInstance();
    }

In real life you would set the driver name, connection URL and username and password to their appropriate values.

Implement your test methods

For this example, we are going to test an insert into the db.

    public void testInsert() throws Exception {
        // insert a customer into the database
        Customer customer = _customerFactory.create("John", "Smith");
        customer.setStreet("1 Main Street");
        customer.setCity("Anycity");
        _customerFactory.update(customer);
...

The code for the CustomerFactory and Customer are at the end of this post.

The data that has just been entered into the database becomes your actual assertable values. Go get them.

        // get the actual table values
        IDatabaseConnection connection = getConnection();
        IDataSet databaseDataSet = connection.createDataSet();
        ITable actualTable = databaseDataSet.getTable("CUSTOMER");

The values defined in customer-expected.xml are what you expect the values to be. Go get them.

        // get the expected table values
        IDataSet expectedDataSet = new FlatXmlDataSet(
                                          new FileInputStream("customer-expected.xml"));
        ITable expectedTable = expectedDataSet.getTable("CUSTOMER");

Check the actual against the expected and complain or not as the case may be.

Assertion.assertEquals(expectedTable, actualTable);
}[/sourcecode]
A version that uses a JUnit class as a wrapper around the DBUnit code looks like this:

/**
 * This is an example only! Use it for anything else at your own risk!
 * You have been warned! Coder/user beware!
 *
 * copyright 2009 Carlos Valcarcel
 */
package hiddenclause.example.dbunit;

import java.io.FileInputStream;

import org.dbunit.Assertion;
import org.dbunit.IDatabaseTester;
import org.dbunit.JdbcDatabaseTester;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.ITable;
import org.dbunit.dataset.xml.FlatXmlDataSet;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author carlos
 */
public class CustomerJunitTest {

    private CustomerFactory _customerFactory;

    private IDatabaseTester databaseTester;

    @Before
    public void setUp() throws Exception {
        databaseTester = new JdbcDatabaseTester("org.hsqldb.jdbcDriver",
                                                "jdbc:hsqldb:hsql://localhost/xdb",
                                                "sa", "");
        // initialize your dataset here
        IDataSet dataSet = new FlatXmlDataSet(new FileInputStream("customer-init.xml"));

        databaseTester.setDataSet(dataSet);

        // will call default setUpOperation
        databaseTester.onSetup();

        _customerFactory = CustomerFactory.getInstance();
    }

    @Test
    public void testInsert() throws Exception {
        // insert a customer into the database
        Customer customer = _customerFactory.create("John", "Smith");
        customer.setStreet("1 Main Street");
        customer.setCity("Anycity");
        _customerFactory.update(customer);

        // get the actual table values
        IDatabaseConnection connection = databaseTester.getConnection();
        IDataSet databaseDataSet = connection.createDataSet();
        ITable actualTable = databaseDataSet.getTable("CUSTOMER");

        // get the expected table values
        IDataSet expectedDataSet = new FlatXmlDataSet(
                                          new FileInputStream("customer-expected.xml"));
        ITable expectedTable = expectedDataSet.getTable("CUSTOMER");

        Assertion.assertEquals(expectedTable, actualTable);

    }

    @After
    public void tearDown() throws Exception {
        databaseTester.onTearDown();
    }
}

Things to notice:
- less configuration (the System.setProperty() calls are gone)
- explicit creation of a IDatabaseTester object
- explicit call to databaseTester.onSetup()
- explicit call to databaseTester.onTearDown()


Run the Database Test

With all the pieces in place it is now safe to run the CustomerTest DBUnit class. You will probably see some warning messages in the Console view about the data type factory being incorrect. You can safely ignore that error for this example. In real life you probably want to instantiate a new DataTypeFactory based on the database you are using.

If any of the above does not quite work as described let me know and I will update the above explanation.

The Code

customer-init.xml

<?xml version="1.0" encoding="UTF-8"?>
<dataset>
    <CUSTOMER />
</dataset>

customer-expected.xml

<?xml version="1.0" encoding="UTF-8"?>
<dataset>
    <CUSTOMER ID="1"
              FIRSTNAME="John"
              LASTNAME="Smith"
              STREET="1 Main Street"
              CITY="Anycity" />
</dataset>

CustomerTest.java

/**
 * This is an example only! Use it for anything else at your own risk!
 * You have been warned! Coder/user beware!
 *
 * copyright 2009 Carlos Valcarcel
 */
package hiddenclause.example.dbunit;

import java.io.FileInputStream;

import org.dbunit.Assertion;
import org.dbunit.DBTestCase;
import org.dbunit.PropertiesBasedJdbcDatabaseTester;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.ITable;
import org.dbunit.dataset.xml.FlatXmlDataSet;

/**
 * @author carlos
 */
public class CustomerTest extends DBTestCase {

    private CustomerFactory _customerFactory;

    public CustomerTest(String name) {
        super(name);
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS,
          "org.hsqldb.jdbcDriver");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL,
          "jdbc:hsqldb:hsql://localhost/xdb");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME,
          "sa");
        System.setProperty(
          PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD,
          "");

        _customerFactory = CustomerFactory.getInstance();
    }

    public void testInsert() throws Exception {
        // insert a customer into the database
        Customer customer = _customerFactory.create("John", "Smith");
        customer.setStreet("1 Main Street");
        customer.setCity("Anycity");
        _customerFactory.update(customer);

        // get the actual table values
        IDatabaseConnection connection = getConnection();
        IDataSet databaseDataSet = connection.createDataSet();
        ITable actualTable = databaseDataSet.getTable("CUSTOMER");

        // get the expected table values
        IDataSet expectedDataSet = new FlatXmlDataSet(
                                          new FileInputStream("customer-expected.xml"));
        ITable expectedTable = expectedDataSet.getTable("CUSTOMER");

        Assertion.assertEquals(expectedTable, actualTable);

    }
    /*
     * (non-Javadoc)
     * @see org.dbunit.DatabaseTestCase#getDataSet()
     */
    @Override
    protected IDataSet getDataSet() throws Exception {
        return new FlatXmlDataSet(
                 new FileInputStream("customer-init.xml"));
    }

}

CustomerFactory.java

/**
 * This is an example only! Use it for anything else at your own risk!
 * You have been warned! Coder/user beware!
 *
 * copyright 2009 Carlos Valcarcel
 */
package hiddenclause.example.dbunit;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;

/**
 * @author carlos
 *
 */
public class CustomerFactory {

    static {
        try {
            Class.forName("org.hsqldb.jdbcDriver");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }

    public static CustomerFactory getInstance()
    {
        return new CustomerFactory();
    }

    public Customer create(String firstName, String lastName) {
        return new Customer(1, firstName, lastName);
    }

    public void update(Customer customer) throws SQLException {
        Connection connection = DriverManager.getConnection("jdbc:hsqldb:hsql://localhost/xdb");
        String sql = "insert into customer (id, firstname, lastname, street, city) values ("
                   + customer.getId() + ", "
                   + "'" + customer.getFirstName() + "', "
                   + "'" + customer.getLastName() + "', "
                   + "'" + customer.getStreet() + "', "
                   + "'" + customer.getCity() + "'"
                   + ")";

        Statement stmt = connection.createStatement();
        stmt.execute(sql);
        if (stmt.getUpdateCount() != 1) {
            throw new SQLException("Insert failed!");
        }
    }

}

Customer.java

/**
 * This is an example only! Use it for anything else at your own risk!
 * You have been warned! Coder/user beware!
 *
 * copyright 2009 Carlos Valcarcel
 */
package hiddenclause.example.dbunit;

/**
 * @author carlos
 *
 */
public class Customer {

    private int _id;
    private String _firstName;
    private String _lastName;
    private String _street;
    private String _city;

    public Customer(int id, String firstName, String lastName) {
        _id = id;
        _firstName = firstName;
        _lastName = lastName;
    }

    public int getId() {
        return _id;
    }

    public String getFirstName() {
        return _firstName;
    }

    public String getLastName() {
        return _lastName;
    }

    public String getStreet() {
        return _street;
    }

    public String getCity() {
        return _city;
    }

    public void setStreet(String street) {
        _street = street;
    }

    public void setCity(String city) {
        _city = city;
    }

}