Marcin Erdmann's blog feed

Including and excluding Spock specifications from execution using a configuration file

2013-09-10T10:30:00Z

It's a common requirement to be able to execute just a subset of your tests in a given situation. Or just run the quick tests locally and run everything on CI. And Spock being an excellent testing framework obviously supports it.

In the past I used Spock's @IgnoreIf and @Require built-in extensions to exclude/include certain specs under given conditions. An example usage for marking some tests to be only run as a part of the CI build could be:

@Require({System.properties.containsKey('ciBuild')})
class SlowSpec extends Specification { ... }

@Require annotation takes a closure. When the closure evaluates to true the annotated specification will be executed otherwise it will be ignored. As you might expect it becomes pretty cumbersome to have to copy that closure body all over the place if you have several specifications that you wish to annotate. Not to even mention...

Using Remote Control plugin to log in into a Grails application with Spring Security backed authentication

2013-05-28T11:00:00Z

In my previous post I wrote about how much I like using grey box testing as a technique for writing functional tests. One common scenario where you could use it is to log in into the application in your tests without having to go to the login page and filling the credentials every single time you need to test something that is available only to logged in users of your system.

Some people will argue that you shouldn't be logging in for every single test that needs the user to be authenticated to be performed. They will use different ways not to have to do so like stepwise Spock specifications or not clearing cookies between tests. But I don't agree with that and I'm happy to pay the price of that little bit of overhead. By starting every single tests from always the same, clear, consistent state, setting up all prerequisites and then clearing cookies and y...

Verifying that Groovy Remote Control endpoint is exposed in your application

2013-05-22T12:00:00Z

I'm a big fun of grey box functional testing of web applications. I understand grey box testing as setting up your test (for example bootstraping data in db that the test requires) programmatically instead of via the UI. Sometimes you will also want to do parts of your verification in this way.

Some people use fixture endpoints for that but I'm not a fan of this solution for two reasons: the fixture code lives along your production code and fixture endpoints are a nightmare to maintain - what people end up doing is to have one endpoint with a lot of setup for all the tests which bootstraps a lot of data that is not essential to every single test... Oh, and there is one more reason - you want your test setup to live as close to your test as possible.

There is a better solution to this problem available for JVM apps - Groovy Remote. It provides an endpoint that allows you to send groovy closures to the remote app...

New in Gradle 1.6: task ordering

2013-05-20T12:00:00Z

Recently Gradle 1.6 has been released. I was lucky enough to get a lot of support from the Gradle team in the means of implementation guidance and code reviews for contributing a new feature: task ordering. Currently it's an icubating feature (see here what it means) and only "must run after" ordering is supported, though it's highly likely that other rules, like for example "should run after" with a slightly less restrictive contract, are coming.

Let's look at a trivial example:

task a
task b {
    mustRunAfter a
}

Executing gradle b will only execute b but executing gradle b a will first execute a and then b. So i...

Gradle Golo Plugin released!

2013-04-23T11:43:00Z

I'm happy to announce the first public release of Gradle Golo Plugin. The plugin allows to build and run code written in Golo using Gradle.

You can have a look at the docs and the example project to learn how to use it.

Resizing browser window in Geb tests

2013-04-08T14:30:00Z

It sometimes proves useful to be able to resize browser window in your Geb tests. Up to not so long ago WebDriver (which is used by Geb to drive browsers) did not provide such a functionality and you had to resort to different hacks that never worked in all of the browsers, but thankfully nowadays it is pretty straightforward.

To make sure that the browser window is maximised before any tests are executed we can add the following to the driver closure in GebConfig.groovy:

driver = {
    def driverInstance = new FirefoxDriver()
    driverInstance.manage().window().maximize()
    driverInstance
}

One of the possible usages of browser window resizing can be testing responsive sites. So for example if we want to write a specification that performs some tests on the site laid out as for an iPhone 4 and then maximise the site when done we could use the following:

class IPhone4Spec extends GebSpec {

    vo...



Mocking browser timers in Geb tests
2013-04-05T19:00:00Z
Functional tests are usually slow enough and you want to avoid any unnecessary waiting in them. But what should you do if the site you're testing is using animated elements? By simply putting waitFor {} blocks to wait for the animation to finish you're just wasting precious time.

But there is a simple solution - you can easily mock browser timers using sinon.js. Let's see how we can use it in Geb tests to make them faster when testing an example Grails application that contains a carousel.

Assuming that we're using Resources plugin, we'll first need to define a resource module that contains sinon.js and a simple Javascript file that will trigger timer mocking:

modules = {
    fakeTimer {
        resource '/js/test/sinon.js'
        resource '/js/test/fakeTimer.js'
    }
}


In fakeTimer.js file we need to assign the mocked timer to a global variable so that we can t...


Setting system properties for JUnit run configurations in Intellij using Gradle
2013-03-06T08:00:00Z
There is one particular Gradle feature that I couldn't live without - IDE project generation. Firstly it means that there are no more IDE specific files in your repository. Secondly it is a perfect tool to easily and quickly generate IDE project configuration files in a repeatable and customisable manner.

There are currently two IDE plugins that gradle ships with Eclipse plugin and IDEA plugin. In this post I will describe how to use the latter to customise the generated project configuration files for IntelliJ.

There are three types of Intellij project configuration files - project files (.ipr), module files (.iml) and workspace files (.iws). While Gradle provides a DSL for modyfing those files (at least for project and module files) quite often you will have to revert to using withXml {} hook to do n...


Specifying git revisions using a commit message
2013-03-04T14:30:00Z
Sometimes when I want to rebase some commits in git I cannot be bothered to copy and paste commit hash or calculate how many commits behind HEAD the commit I want to rebase onto is to be able to use the HEAD~N notation. 

Recently I've learned from gitrevisions manual that you can also specify a git revision using the :/<text> notation where <text> is a regular expression applied against commit messages. Unfortunately it doesn't work with git rebase complaining that it expects a single revision. But you can always use git rev-parse to resolve a git commit hash:

git rebase -i $(git rev-parse ":/some commit message")



Test driving Gaelyk applications talk from GGX and Greach
2013-01-26T09:21:00Z
The slides from my 'Test driving Gaelyk applications' I gave at Groovy and Grails eXchange 2012 and Greach 2013 are available here.

The example application is available at github.

If you missed it you can still see the recording of the talk from GGX.