Spock: Using ConfineMetaClassChanges when using MetaClass mocking

Posted on November 19, 2014 by Albert van Veen

One of the handy features of Groovy is to change the behavior of classes using MOP (Meta-Object Protocol). We change the metaClass property of a class to alter an implementation. You can for example override a static method of a class. See the example below:

class UserSpec extends Specification {

    def “test user”() {
        given:
        // we can mock static methods...
        User.metaClass.static.findByName = { name -> 
            new User(name: ‘Albert’) }
        when:
        User user = User.findByName(‘Albert’)

        then:
        user.name == ‘Albert’

        when:
        // .. but also non-static methods
        user.metaClass.getName = { return ‘Dries’ }

        then:
        user.name == ‘Dries’
    }

}

class UserSpec extends Specification {

def “test user”() {

given:

// we can mock static methods...

User.metaClass.static.findByName = { name ->

new User(name: ‘Albert’) }

when:

User user = User.findByName(‘Albert’)

then:

user.name == ‘Albert’

when:

// .. but also non-static methods

user.metaClass.getName = { return ‘Dries’ }

then:

user.name == ‘Dries’

}

However this way of mocking has a nasty side effect. Since we apply changes on the User on class level, the changes are also applied in all our other test cases. This can have some unexpected behavior in your other tests

To prevent this Spock has introduced the @ConfineMetaClassChanges annotation. This annotation makes sure the class will return to its original state when it was used in our test.

See the example below:

@ConfineMetaClassChanges([User]) // you can add multiple classes in the annotation
class UserSpec extends Specification {
...
}

@ConfineMetaClassChanges([User]) // you can add multiple classes in the annotation

class UserSpec extends Specification {

...

}

Be aware: this means when some other test did changes to the User class without using @ConfineMetaClassChanges, these changes will be still applicable when the test which has @ConfineMetaClassChanges restores the User class to its old state.

Spocklight: Indicate Class Under Test with Subject Annotation

Posted on October 14, 2014 by mrhaki

If we write a specification for a specific class we can indicate that class with the @Subject annotation. This annotation is only for informational purposes, but can help in making sure we understand which class we are writing the specifications for. The annotation can either be used at class level or field level. If we use the annotation at class level we must specify the class or classes under test as argument for the annotation. If we apply the annotation to a field, the type of the field is used as the class under test. The field can be part of the class definition, but we can also apply the @Subject annotation to fields inside a feature method.

Continue reading →

Spocklight: Write Our Own Data Provider

Posted on June 26, 2014 by mrhaki

We can use data pipes to write data driven tests in Spock. A data pipe (<<) is fed by a data provider. We can use Collection objects as data provider, but also String objects and any class that implements the Iterable interface. We can write our own data provider class if we implement the Iterable interface.

Continue reading →

Spocklight: Ignore Specifications Based On Conditions

Posted on June 23, 2014 by mrhaki

We can use the @Ignore and @IgnoreRest annotation in our Spock specifications to not run the annotated specifications or features. With the @IgnoreIf annotation we can specify a condition that needs to evaluate to true to not run the feature or specification. The argument of the annotation is a closure. Inside the closure we can access three extra variables: properties (Java system properties), env (environment variables) and javaVersion.

Continue reading →

Spocklight: Extra Data Variables for Unroll Description

Posted on June 19, 2014 by mrhaki

Spock’s unroll feature is very powerful. The provider data variables can be used in the method description of our specification features with placeholders. For each iteration the placeholders are replaced with correct values. This way we get a nice output where we immediately can see the values that were used to run the code. Placeholders are denoted by a hash sign (#) followed by the variable name. We can even invoke no-argument methods on the variable values or access properties. For example if we have a String value we could get the upper case value with #variableName.toUpperCase(). If we want to use more complex expressions we must introduce a new data variable in the where block. The value of the variable will be determined for each test invocation and we can use the result as a value in the method description.

Continue reading →

Grails Goodness: Run Forked Tests in IntelliJ IDEA

Posted on February 11, 2014 by mrhaki

In the latest Grails releases we can execute our tests in so-called forked mode. This means a separate JVM is started with an isolated classpath from the Grails build system. When we want to run our tests in forked mode from within IntelliJ IDEA we get the following error: Error running forked test-app: Could not load grails build listener class (Use --stacktrace to see the full trace). To make running tests in forked mode work with IntelliJ IDEA we must add one of the IntelliJ IDEA supplied JAR files to the Grails classpath.

Continue reading →

Spocklight: Using the Old Method

Posted on August 23, 2013 by mrhaki

Spock has some great features to write specifications or tests that are short and compact. One of them is the old() method. The old() method can only be used in a then: block. With this method we get the value a statement had before the when: block is executed.

Continue reading →

Using ArgumentMatchers with Mockito

Posted on April 12, 2013 by Albert van Veen

Mockito is a mock framework which you can use to write simple and clean tests. One of it’s nice features is the ArgumentMatcher. With the ArgumentMatcher you can determine the outcome of your mocked service or repository based on any condition you want.

Imagine we have a CandyService which can get a list of candies which are liked by a specific customer. This service uses the external ChocalateService which specifically checks if the customer likes chocolate. Continue reading →

Tasty Test Tip: Test final and static methods with PowerMock and Mockito

Posted on October 3, 2012 by Arthur

Two of the most famous mocking frameworks EasyMock and Mockito, don’t offer out of the box support for mocking final and static methods.

It is often said on forums that “you don’t want that” or “your code is badly designed” etc. Well this might be true some of the time, but not all of the time. Continue reading →

Tasty Test Tip: Using ArgumentCaptor for generic collections with Mockito

Posted on October 1, 2012 by Arthur

Mockito has a very nice feature that allows you to verify what parameters were used when a method was executed.

For example:

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);

verify(mock).doSomething(argument.capture());

assertEquals("John", argument.getValue().getName());

However, when using generic typed objects, some problems rise up.
For example, the following won’t work:

ArgumentCaptor<List<Person>> argument = ArgumentCaptor.forClass(List<Person>.class);

1	ArgumentCaptor<List<Person>> argument = ArgumentCaptor.forClass(List<Person>.class);

This is obviously not a Mockito problem, but a generics problem.

To solve this, follow these two steps:

1. use the @Captor annotation.

    @Captor
    private ArgumentCaptor<List<Person>> argumentCaptor;

1 2	@Captor private ArgumentCaptor<List<Person>> argumentCaptor;

2. initialize the Mockito annotations in your initialization method (add one if you don’t have one).

    @Before
    public void init(){
       MockitoAnnotations.initMocks(this);
    }

@Before

public void init(){

MockitoAnnotations.initMocks(this);

}

And presto! You can now capture the parameters that were used when a to be verified method was executed.

 verify(someMock).someMethod(argumentCaptor.capture());

1	verify(someMock).someMethod(argumentCaptor.capture());