Smoketest Dogs

When working on a very large project, quality is of the essence. One key part of adding quality to a software project, is by testing.

You have several ways of testing an application. We used unit testing, integration testing, selenium testing. But due to a big difference between our local testing environment (tomcat server) and our test teams environment (websphere), we have to check our release when it is deployed on the test teams environment.
We used the principle of smoke testing. Doing some basic actions and see that the application is still stable. Only big failures are fixed in the release. When we discover a bug, we register it in our bug tracker and it is fixed in the next release.

I think we could also usedĀ Arquillian. Arquillian is a framework that wraps your integration test into the container you run them in. Unfortunately Arquillian wasn’t an option. We had to do the test manually.

We started with creating a checklist that is hosted on our local wiki.
This way, we make sure that everything is checked before we migrate our release to the testers. Simple, but very efficient.

We are using this checklist, but every release, everyone tests the same features. This leads into cases where someone always tests the same way. This way, some essential things could be forgotten.

We wanted to create a system where we cycle over test, so each group of test is executed by someone else, with enough rotation to make sure no testing habit is developed.

We wanted to keep this a bit fun, because no one really likes doing smoke tests.

The smoke test dogs came to life.
The idea is simple, the tests on the checklist have a certain color. there are as many colors as there are characters in Quentin Tarantino‘s movie, Reservoir dogs.

The day of the release, everyone picks a card in the scrum stand-up meeting. This indicates what test should be executed.
We have a placeholder in our office where the cards should hang when all the test are succeeded. When all the cards are back, we are ready to release to our testers.

This is a very simple way to keep testing fun for everyone. The only disclaimer, this could lead to some role playing šŸ˜‰
Big thanks to my collegues @erwinravau, @jordanvermeir, @jaspervdm, Cindy and Maarten

And if you aren’t there, you’re mr. pink!
If you're not there, you're mr Pink!

Why you should never use getSingleResult() in JPA

As long as I’m using JPA I notice that the use of getSingleResult and getResultList is often confused. In the javadoc there is no clear specification of what to use.

Execute a SELECT query and return the query results as an untyped List.


Execute a SELECT query that returns a single untyped result.

So this doesn’t get us much further. So lets explore the problem. Both methods are used to retrieve Entities from our database. We use the getResultList() if there is no guarantee how many results we want to retrieve, the getSingleResult is used to retrieve exactly one row.
So the only doubt for what method to use, is when we retrieve 1 row from our database. A perfect example for this use-case is a findById query, where we retrieve an Entity based upon its ID.
There are 3 ways to do this. The most appropriate way is to use the EntityManger.find() method. This method returns a typed instance of the entity when it is found, null when it is not found.
The other 2 ways is by a NamedQuery. Why would we want to use a NamedQuery when we have the find method? Sometimes we need to retrieve a lazy collection, by adding a fetch join. An other example is when we have a composite key, we can still use the EntityManager.find() method, but I often see the use of a named query in this case. (don’t do this, bad programming)
So we created our named query

final Query query = getEntityManager().createNamedQuery("Entity.findById");
query.setParameter("id", id);

The most natural reaction is to call the getSingleResult() method on the query. This returns only one row and the result of a ‘findById’ query should only be one row. But what if the row isn’t in the database (anymore)? We get an unchecked exception: NoResultException. Is this what we expect?
If you look in Effective Java by Joshua Bloch, we read: ‘Use checked exceptions for conditions from wich the caller can reasonably be expected to recover. Use runtime exceptions to indicate programming errors’.
So what does this tell us? When a getSingleResult Query returns no rows, we get an unchecked exception, thus a programmer error, there is no way to recover from this. This is not correct. We never know for sure what we can expect from our database, so throwing an unchecked exception seems the wrong choice for this use-case.
The only use for getSingleResult() is when we are executing a scalar (count, sum, avg) query. This is a query wich will alway return a row, otherwise we are in an exceptional case, so the exception is allowed.
So, how do we solve our example with our named query? Simple

List results = query.getResultList();
Entity foundEntity = null;
    // ignores multiple results
    foundEntity = results.get(0);

Extending Spring JUnit Runner

For our integration tests we had to use the development database. On that database there are some batch parameters stored and one of those parameters is a cutoffTime. As the name suggest, our business logic can not be processed after that time, so we had to create a mechanism to make sure that the tests are not executed, else the build would fail.
The first thing we did was a quick fix. We added an if-statement to the test to see what time it is and if the test can be executed. As some of you already know, an empty method annotated with @Test will execute and be successful. This is not correct, when someone breaks code that is in those tests, the test should not be marked as successful. We should be able to add the @Ignore annotation on the tests when the cutOffTime is passed.

I looked into this problem and the first thing that came to my mind was to use Annotations, because it is meta-data and not test functionality. JUnit4 has a very easy way to handle annotations, so I decided to go that way.

 * The CutOffTime annotation..
public @interface CutOffTime {
    String cutOffTime();

I want this annotation to cancel all my tests in a testcase, not just a method, that is why i put the ElementType on TYPE.

Our integration tests are running with the SpringJUnit4ClassRunner so I extended this. I have overridden the invokeTestMethod method, because this is the one executing each test. Here is the source code

 * The Class IntegrationTestClassRunner. This class is a specific class runner
 * for the payments. There is a cutoffTime defined in the database that decides
 * if a payment that can be made or not. This can be applied by the
 * {@link CutOffTime} annotation
 * @author Jelle Victoor
 * @version 14-apr-2010
public class IntegrationTestClassRunner extends SpringJUnit4ClassRunner {

     * The Constructor.
     * @param clazz
     *            the clazz
     * @throws InitializationError
     *             the initialization error
    public IntegrationTestClassRunner(final Class<?> clazz) throws InitializationError {

    /** {@inheritDoc} */
    protected void invokeTestMethod(final Method method, final RunNotifier notifier) {
        Annotation[] classAnnotations = classAnnotations();
        Boolean ignore = Boolean.FALSE;
        for (Annotation classAnnotation : classAnnotations) {
            if (classAnnotation instanceof CutOffTime) {
                if (shouldIgnore(((CutOffTime) classAnnotation).cutOffTime())) {
                    ignore = Boolean.TRUE;
        if (!ignore) {
            super.invokeTestMethod(method, notifier);
        } else {

     * Decides to ignore the test
     * @param cuttOffTime
     *            the cutt off time
     * @return true, if should ignore
    private boolean shouldIgnore(final String cuttOffTime) {
        int hour = Integer.parseInt(StringUtils.substring(cuttOffTime, 0, 2));
        int minutes = Integer.parseInt(StringUtils.substring(cuttOffTime, 2, 4));
        return new LocalTime().isAfter(new LocalTime(hour, minutes));

As you can see, the classAnnotation() method will give you all the annotations that are on your class *and are specified with @Retention(RetentionPolicy.RUNTIME)*. I simply check if the annotation is found on the class. When I’m done checking if the annotation is found and if the test should be ignored, i can fireTestIgnored on the notifier or execute the test. We just annotate our tests with @RunWith(IntegrationTestClassRunner.class).
This way the test should not fail or succeed, but now you can simply see that the test is ignored. The statistics are clean :-).

I know that the whole purpose of this extention is odd, but we are forced into this position. With this post I’m trying to show you that extending a test framework like JUnit isn’t hard at all and you can use it in every way you want to.

Java EE annotations in Spring

Since I began programming I noticed that annotations kept gaining popularity. Implementing a marker interface is in many cases replace by adding an Annotation.

Even in Spring. Spring added the support tor the java EE annotations. Here’s a little example. Instead of implementing the initializingBean Interface, you can simply use theĀ @PostConstruct van Java EE 5.

All callback handler used in EE5+ are possible in Spring. you only have to configure theĀ CommonAnnotationBeanPostProcessor in your spring context.

/** {@inheritDoc} */
public void afterPropertiesSet() throws Exception {


/** Postconstuction method */
public void myMethod() {

It is a small nuance, but I personally like this way of working. I don’t chose annotations over interfaces in every case, but when we are talking about callback handlers, I think it the better way. Your implementation doesn’t include strange spring specific methods, but methods that make sense to you and your other developers. It just has a little annotation above it.