apply plugin: 'jacoco'

to your build.gradle, and run ./gradlew jacocoTestReport and it.. does nothing. For those running into the same issues, this might save you a bit of time:

After a bit of searching, it turns out the jacoco plugin is a bit broken. When using it with a Java project, as I’m doing, you need to do a couple of things to enable it, but also then, it unfortunately doesn’t work as advertised, though the fix seems not to complex.

First, you need to enable the following:

jacocoTestReport {
    group = "Reporting"
    description = "Generate Jacoco coverage reports after running tests."
    additionalSourceDirs = files(sourceSets.main.allJava.srcDirs)
}

And then, instead of running ./gradlew jacocoTestReport as mentioned in the docs here, you need to run ./gradlew test jacocoTestReport. Unfortunately, no location is printed where the documentation is created, so no clickable links in your terminal, but you can find it under build/reports/jacoco/test/html/index.html. Well, that wasn’t so bad now, was it? Have fun!

I found a pretty neat Gradle script in their Jira system, which can create a directory structure for you even when working on a Groovy or Scala project. The easiest way to do so is to add the following ‘initProject’ task to the Gradle build.gradle:

apply plugin: 'java'
apply plugin: 'groovy'

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.0.5'

    testCompile group: 'junit', name: 'junit', version: '4.+'
}

task initProject () << {
    if (hasProperty(initPlugins)) {
        initPlugins.split(',').each { plug -> 
            project.apply { 
                plugin(plug.trim()) 
            } 
        }
    }

    project.sourceSets*.allSource.srcDirTrees.flatten().dir.each { dir ->
        dir.mkdirs()
    }
}

You can call it by executing the following command:

gradle initProject -PinitPlugins=groovy,java

This works great until Hans or Luke decide to create the

gradle create-project myproject -PapplyPlugin=java,groovy

command, which would make our lives even easier!

When Groovy 2.0 came out, not a lot of things had happend on the book. Sure, there were new some new chapters written, but there were also still 18 other chapters to write. So it was time for some Action. So, some time ago, just before a Grails Exchange far away, yours truly wrote Dierk, and with the famous words: “hee Dierk, wtf is going on with the book?”, was he invited in joining the musketeers. Ha, he thought, this is my chance on fame and fortune! So imagining the screaming girls, the fireworks, the rains of golden coins, I signed the contract with my blood, and joined the party. And what a party it was. It was more like a pack of brigands than the musketeers! Ohohoh, what had I signed up for? So, when the Grails Exchange really came, a chat with Guillaume was needed. So we did, after a great chat, some great ideas, and full of energy, we parted and… Nothing happened. All the things I had to do, for all the great ideas we had, I did nothing. Also I was to busy to get things going! But then, a voice from the sky came, which got us all by surprise. It was our great publisher, Manning, demanding progress. And he got it.

So, after almost one year of inactivity, a great motivation, and a lot of talks, we published a new version of the Groovy in Action MEAP! There’s an updated chapter on the GDK, created by yours truly! So no, the project is not dead. Really, trust us when we say we’re working hard, really hard, on finishing this great book! We’re all heavily motivated in delivering THE best book on Groovy, so no, the project is not dead, it was merely in hibernation, and yes, we will deliver this book. It will still take a bit of work, but another chapter is just finished (another one by me, this time about Groovy and Testing), with features about Spock, Gradle and many other improvements, and other chapters will follow soon. So keep spamming the forums, keep spamming the authors, keep us sharp, and shout your interested. We will deliver!

To do so, you can use AlarmClock.

This can be done in the following way:

Intent openNewAlarm = new Intent(AlarmClock.ACTION_SET_ALARM);
openNewAlarm.putExtra(AlarmClock.EXTRA_HOUR, 0);
openNewAlarm.putExtra(AlarmClock.EXTRA_MINUTES, 20);
startActivity(openNewAlarm);

You’ll need to add the right security permission to your manifest though:

A small note: there’s no way to cancel the alarm after the intent has been sent. If you need more control over your alarm, you’ll need to to use something like the AlarmManager anyway, which provides more control over your set alarm, like cancelling.

In many software projects I encounter code like the following:

assertEquals("Collection size doesn't match", 4, reds.size());

Or, even worse:

assertTrue(greens.size() == 0);

The second loses context by not knowning the expected value and the actual value; it knows only that they are not equal.

So, while this above might be a valid asserts, their readability and error feedback can be improved by using a framework like Hamcrest. This can be done in the following way:

assertThat(reds, hasSize(4));
assertThat(greens, is(empty()));

In my opinion, this increases readability quite a bit, and makes it easier to maintain tests like this. Check the following piece of code for more examples:

    @Test
    public void testIterablesMatchers() {
        Catalogue catalogue = new Catalogue();

        catalogue.addMovie(new Movie("Lord of the Rings"));
        catalogue.addMovie(new Movie("The Ring"));
        catalogue.addMovie(new Movie("The Bling Ring"));

        List movies = catalogue.getMovies();

        // Check each item for a certain condition
        assertThat(movies, everyItem(Matchers.hasProperty("title", containsString("Ring"))));

        // Checks that the collection has at least one item which matches the specified matcher.
        assertThat(movies, hasItem(new Movie("The Ring")));
        // Checks that the collection has at least one or multiple items which match the specified matcher.
        assertThat(movies, hasItems(new Movie("The Ring"), new Movie("Lord of the Rings")));

        // Creates a matcher matching examined iterables that yield no items.
        assertThat(new ArrayList(), emptyIterable());

        // Checks that all of the items match the expected items, in the same order.
        assertThat(movies, contains(new Movie("Lord of the Rings"), new Movie("The Ring"), new Movie("The Bling Ring")));
        // Checks that all of the items match the expected items, in any order.
        assertThat(movies, containsInAnyOrder(new Movie("The Ring"), new Movie("The Bling Ring"), new Movie("Lord of the Rings")));

        // Beware here: iterableWithSize is a bit funky with Generics, so the bast (and only) way to solve this is to be explicit about the generics
        assertThat(Arrays.asList("foo", "bar"), IsIterableWithSize.iterableWithSize(2));

        // Matches when the size() method returns a value equal to the specified size.
        assertThat(movies, hasSize(3));

        // Checks that the examined collections whose isEmpty method returns true.
        assertThat(new ArrayList(), is(empty()));
        // Checks that the examined collections whose isEmpty method returns true.
        assertThat(new ArrayList(), is(emptyCollectionOf(Movie.class)));
    }

Error messages

Whenever a assertion fails, you get a pretty clear error message, which will help you quickly solve issues you run into. For example, if in the above code example I would have made a wrong assumption, and instead of:

        assertThat(movies, hasSize(3));

If would have typed:

        assertThat(movies, hasSize(2));

The following error message would have shown up:

java.lang.AssertionError:
Expected: a collection with size 
     but: collection size was 

Whereas the the JUnit equivalent:

assertEquals(2, movies.size());

Would have resulted in the following:

junit.framework.AssertionFailedError:
Expected :2
Actual   :3

Which would have helped a great deal also, but it’s just that the Hamcrest one is a bit more clear, and a bit more elaborate on the error message.

I hope this helps in picking up Hamcrest and that it helps in writing clear, consistent tests. See you next week!

The Hamcrest String Matchers are the following:
containsString, startsWith, endsWith, equalToIgnoringCase, equalToIgnoringWhitespace, isEmpty, isEmptyOrNull and stringContainsInOrder

Also in this post, I will give an example of all of them in the code block below:

    @Test
    public void testMovieStringMatchers() {
        // Setting up our class to test here.
        Movie movie = new Movie("Charlies Angels");
        movie.setDescription("");
        movie.setDirector(null);
        movie.setStoryLine("The captivating crime-fighting trio who are the masters of disguise, espionage and martial arts.");

        // Checks that the actual result contains the specified String
        assertThat(movie.getTitle(), containsString("Angels"));
        // Checks that the actual result starts with the specified String
        assertThat(movie.getTitle(), startsWith("Charlies"));
        // Checks that the actual result ends with the specified String
        assertThat(movie.getTitle(), endsWith("Angels"));

        // Checks that the actual result equals the specified String, ignoring casing
        assertThat(movie.getTitle(), equalToIgnoringCase("charlies angels"));
        // Beware: this method work different than you would expect, since it doesn't ignore whitespaces: it ignores most of them. Check the Javadoc.
        assertThat(movie.getTitle(), equalToIgnoringWhiteSpace(" charlies  angels   "));

        // Checks that the actual result is an empty String
        assertThat(movie.getDescription(), isEmptyString());
        // Checks that the actual result is null or an empty String
        assertThat(movie.getDirector(), isEmptyOrNullString());

        // Checks that the actual result contains the specified Strings in this sequence
        assertThat(movie.getStoryLine(), stringContainsInOrder(Arrays.asList("The", "trio", "arts")));
    }

Again, the Hamcrest assertions are very clear, and makes your testcode a easier to read an maintain. Enjoy!

• Open a class file
• Press Alt + Insert or Ctrl + N to popup the ‘Generate’ menu
• Choose toString()
• Click the button named ‘Settings’
• Go to the ‘Templates’ tab
• Create a new template named
• Add the following in the template:

public String toString() {
#set ($autoImportPackages = "com.google.common.base.Objects")
   return Objects.toStringHelper(this)
#foreach ($member in $members)
   .add("$member.name", $member.accessor)
#end
   .toString();
}

IntelliJ toString settings window

This template is based on the Apache Commons toStringBuilder, and will generate a consistent toString for you using Google Guava.

In our previous post, we got a small introduction into Hamcrest, a framework for writing test matcher objects, and why you should use them. This post will dive deeper into Hamcrest Matchers. A Matcher is a ‘match’ rule to be defined declaratively. The Hamcrest library comes with numerous matchers included, and it’s of course possible to write your own Matcher.

The topic of this week: the Core Matchers.

The common Matchers of Hamcrest are the following:
is, equalTo, not, anything, instanceOf, any, isA, nullValue, notNullValue, sameInstance, theInstance, isIn, isOneOf and hasToString.

I will give an example of all of them in the code block below:

    @Test
    public void testMovie() {
        // Creation of class under test.
        Movie movie = new Movie("Charlies Angels");
        movie.setInStock(false);
        movie.addGenre(ACTION);
        movie.addGenre(COMEDY);

        Movie otherMovie = movie;

        // This is method takes just a value, instead of a matcher.
        assertThat(movie.isRentable(), is(false));

        // This not method also just takes a value
        assertThat(movie.isRentable(), not(true));
        // This is a chained example for better readability, where the 'is' method takes the not matcher as an argument
        assertThat(movie.isRentable(), is(not(true)));

        // This is a simple String comparison
        assertThat(movie.getTitle(), equalTo("Charlies Angels"));
        // And can also be done this way:
        assertThat(movie.getTitle(), is("Charlies Angels"));

        // Anything always matches. Seriously, no idea what to use this for.
        assertThat(movie, is(anything()));

        // Checks the type of the object. Movie implements the Rentable interface
        assertThat(movie, is(instanceOf(Rentable.class)));

        // Matches when the examined object is an instance of the specified type, used eg. by JMock's with method.
        assertThat(movie, any(Movie.class));

        // Shortcut for is(instanceOf(SomeClass.class))
        assertThat(movie, isA(Rentable.class));

        // Checks if the object is null
        assertThat(new Movie(null).getTitle(), is(nullValue()));
        // Checks if the object is not null
        assertThat(movie.getTitle(), is(notNullValue()));

        // Check that the objects are the same instance
        assertThat(movie, is(sameInstance(otherMovie)));
        // Check that the objects are the same instance. Same as 'sameInstance'.
        assertThat(movie, is(theInstance(otherMovie)));

        // Checks if the examined object is found within the specified array.
        assertThat(movie.getMainGenre(), isIn(Arrays.asList(ACTION, DRAMA)));
        // Seems the same as 'isIn', but this is the varargs variant.
        assertThat(movie.getMainGenre(), isOneOf(ACTION, DRAMA));

        // Checks the toString of the tested object.
        assertThat(movie, hasToString("Movie{inStock=false, title=Charlies Angels, ratings=[]}"));
    }

As you can see, the Hamcrest assertions are very readable, and makes your testcode a bit easier to maintain.

PS: I always wanted to write some posts about Hamcrest, but the thing which really triggered me was the Hamcrest cheat sheet created by Marc Philipp. Be sure to check it out, it’s a great piece of work!

assertEquals("Result doesn't match hello", "hello", result.getValue())

Should not be unfamiliar to you. This blogpost is on improving the example above. There are good alternatives in writing your tests, like Spock, but these take a little more effort to setup, since it’s mostly used in Groovy projects. The goal of this blogpost is to improve the above Java test with little effort, and for that, we’re going to use Hamcrest.

Hamcrest is (in our case) a set of Java matchers which improve the readability of the code and error messages shown when assertions do not match. So, let’s get back to our original example: what does it really say?

assertEquals("Result doesn't match hello", "hello", result.getValue())

Means something like: verify that the getValue method of result should return the String hello, and if not, print the message ‘result doesn’t match hello’. Wouldn’t it be more understandable if we could write something like this in a more natural language? Well, with Hamcrest we can:

assertThat(result.getValue(), is(equalsTo("hello"))

In this example, we’re using ‘assertThat’, which is a method coming from JUnit. JUnit itself supports a random amount of Matchers, but I would recommend on forgetting those, and just use only the Matchers from Hamcrest itself (which means, adding the Hamcrest library to the project, version 1.3 at this moment), since the Hamcrest library contains a much bigger set of Matchers. Also, note that the ‘is’ method here is optional, but I added it to improve readability.

Hamcrest can be added to your Maven project by including the following dependency:

  org.hamcrest
  hamcrest-all
  1.3

And using this library, you’ll get many matchers, supporting String, Collections, Maps, Numbers, and even XML elements, but more on that in my next blog!

One last note: be aware to use the latests version of JUnit though (currently 4.11). When using an older version you might (read: will) run into dependency issues. Don’t say I didn’t warn you!

To use it, you need to add a listener your web.xml. Be careful to place this before the ContextLoaderListener entry. Also important is to add a log4jRefreshInterval (in milliseconds), else Log4j won’t start it’s deamon thread.

web.xml

<context-param>
  <param-name>log4jConfigLocation
  <param-value>classpath:log4j.xml 
</context-param>
<context-param>
  <param-name>log4jRefreshInterval
  <param-value>1000
</context-param>

<context-param>
  <param-name>contextConfigLocation
  <param-value>classpath:/application-context.xml
</context-param>

<listener>
  <listener-class>org.springframework.web.util.Log4jConfigListener
</listener>

<listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener
</listener>

This should reload your log4j.xml changes whenever they occur.