There is really no excuse to not write unit tests in Grails. The support for writing tests is excellent, also for testing code that has to deal with the locale set in a user's request. For example we could have a controller or taglib that needs to access the locale. In a unit test we can invoke the addPreferredLocale() method on the mocked request object and assign a locale. The code under test uses the custom locale we set via this method.

In the following controller we create a NumberFormat object based on the locale in the request.

Continue reading →

Grails adds a couple of methods and properties to our controller classes automatically. One of the methods is the header() method. With this method we can set a response header with a name and value. The methods accepts two arguments: the first argument is the header name and the second argument is the header value.

In the following controller we invoke the header() method to set the header X-Powered-By with the Grails and Groovy version.

Continue reading →

NOTE: this blog post was written for version 0.8 of the Karma test runner. An updated blog post for the new Karma 0.10 can be found here.

For my current project we are using Maven to build our AngularJS application. Furthermore we use Sonar (recently renamed to SonarCube) to monitor our code standards / best practices and unit test coverage. In this blog post we describe how to integrate the Karma (Testacular) test runner with Maven and how to add your AngularJS (or any JavaScript) application to SonarQube.

Continue reading →

When we want to clone an object there are several ways to do this For instance we can implement Clonable, which makes it possible to duplicate an object. We also can create a new object manually by calling each setter or use a parameterised constructor. In case we want to clone a Hibernate object, there is an extra option available which is more elegant: the Hibernate3BeanReplicator. The Hibernate3BeanReplicator is provided by Beanlib (http://beanlib.sourceforge.net/) and it supports deep clones, so we can also clone related one-to-one objects easily. For example we want to clone the Student object, including all child (one-to-one) objects.

Student student = studentDao.getStudentById(1);

HibernateBeanReplicator replicator = new Hibernate3BeanReplicator();
Student studentCopy = replicator.deepCopy(student);

studentCopy.setId(null);
studentCopy.getRelatedObject().setId(null);

studentDao.save(studentCopy);

Continue reading →

Say you have a arbitrary class under test, which is dependent on a class DataProcessor which has a method with the following signature:

 String processData(String data, MultivaluedMap  params, Token token)

Continue reading →

To add logging to a class with Groovy is easy. We apply one of the logging AST transformations and we get a variable in our class named log. We can invoke methods on the variable and the AST transformation will also automatically wrap those statement in a "if-logging-level-is-enabled" block. The transformation is even intelligent enough to do this only if Strings are added or a GString is used. If we want to use a different name than log we simply use the value parameter of the annotation. We assign the name we want to use and then we can use it in our code.

import groovy.util.logging.*

@Log(value = 'LOGGER')
class Event {
    String name
    Boolean started

    void start() {
        LOGGER.info "Event $name is started"
        started = true
    }
}

final Event event = new Event(name: 'gr8Conf')
event.start()

Continue reading →

Gradle already has a powerful DSL, but Gradle wouldn't be Gradle if we couldn't extend the DSL ourselves. Maybe we have our own naming conventions in our company or we have a special problem domain we want to express in a Gradle build script. We can use the ExtensionContainer, available via project.extensions, to add new concepts to our build scripts. In the Standardizing your enterprise build environment webinar by Luke Daley some examples are shown on how to extend the DSL. Also in the samples folder of the Gradle distribution are examples on how to create a custom DSL.

Let's first create a simple DSL extension. We first define a new class CommonDependencies with methods to define dependencies in a Java project. We want to use these methods with descriptive names in our build scripts. To add the class we use the create() method of the ExtensionContainer. The first argument is a name that needs to be unique within the build. The name can be used together with a configuration block in the script to invoke methods on the class we pass as the second argument. Finally we can pass constructor arguments for the class as last arguments of the create() method.

Continue reading →

Groovy 2.1 introduced the @DelegatesTo annotation. With this annotation we can document a method and tell which class is responsible for executing the code we pass into the method. If we use @TypeChecked or @CompileStatic then the static type checker of the compiler will use this information to check at compile-time if the code is correct. And finally this annotation allows an IDE to give extra support like code completion.

Suppose we have the following class Reservation with the method submit(). The method accepts a closure with methods that need to be applied with the instance of the Reservation class. This is a very common pattern for writing simple DSLs in Groovy.

Continue reading →

Apache Wicket is a populair web framework. There are a many reasons why I like to use Wicket, for instance: it offers a great mark-up/logic separation and using Wicket it’s very easy to implement AJAX functionality without writing one line of Javascript.

To provide you with simple and short tips and tricks for Wicket I write this series of blogs. In this first blog of the series I will show you how to create a download link in several ways.

Continue reading →

NOTE: version 7 of WebStorm already comes with built-in Karma support.
However IntelliJ IDEA 12 users will have to wait for v. 13, making this article still relevant for them.

Recently I started using the Karma (previously called Testacular) test runner for JavaScript, as an alternative for the “Jasmine Maven Plugin”. The primary reason for switching is that Karma uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests instead of the emulated Mozilla Rhino JavaScript engine. To increase productivity I wondered if I could also integrate Karma into WebStorm / IDEA. Currently WebStorm doesn't offer out of the box support the Karma test runner. However it does support executing any kind of NodeJS application (like Karma). Installing the NodeJS plugin (only needed when using IDEA Ultimate) When using IntelliJ IDEA Ultimate you first have to manually install the NodeJS plugin. To install this plugin:

Continue reading →

Arthur Arts wrote an blog post about Using ArgumentCaptor for generic collections with Mockito. With the ArgumentCaptor in Mockito the parameters of a method call to a mock are captured and can be verified with assertions. In Spock we can also get a hold on the arguments that are passed to a method call of a mock and we can write assertions to check the parameters for certain conditions. When we create a mock in Spock and invoke a method on the mock the arguments are matched using the equals() implementation of the argument type. If they are not equal Spock will tell us by showing a message that there are too few invocations of the method call. Let’s show this with an example. First we create some classes we want to test:

package com.jdriven.spock

class ClassUnderTest {

    private final Greeting greeting

    ClassUnderTest(final Greeting greeting) {
        this.greeting = greeting
    }

    String greeting(final List<Person> people) {
        greeting.sayHello(people)
    }
}

package com.jdriven.spock

interface Greeting {
    String sayHello(final List<Person> people)
}

package com.jdriven.spock

@groovy.transform.Canonical
class Person {
    String name
}

Continue reading →

NOTE: this post was written for Karma 0.8 which required a manual installation of PhantomJS.
However this blog post is still relevant for installing the NodeJS and NPM pre-requisites.
As of 0.10 both PhantomJS and Chrome will be automatically installed by the launcher plugins.
Installation instructions for Karma 0.10 can be found here (a "Local installation" is preferred).
Furthermore instructions on how to install plugins (introduced as of 0.10) can be found here.

Recently I decided to switch from the “Jasmine Maven Plugin” (using the Mozilla Rhino JavaScript “emulator”) to the Karma (previously called Testacular) test runner. The big advantage of Karma opposed to the “Jasmine Maven Plugin” is that it uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests. This blogpost describes the installation and configuration of Karma on Windows. To install Karma you first need to install NodeJS and its NPM (NodeJS Package Manager). Additionally you could install PhantomJS, a “headless” web-kit browser, to run your JavaScript tests from the command-line without spawning unwanted browser windows. Instead of using PhantomJS as a replacement for testing against real browsers you could use it to run tests on your local development machine while your continuous integration server could then run your tests on “all” relevant browsers.

Continue reading →