Spocklight: Optimize Run Order Test Methods

Spock is able to change the execution order of test methods in a specification. We can tell Spock to re-run failing methods before successful methods. And if we have multiple failing or successful tests, than first run the fastest methods, followed by the slower methods. This way when we re-run the specification we immediately see the failing methods and could stop the execution and fix the errors. We must set the property optimizeRunOrder in the runner configuration of the Spock configuration file. A Spock configuration file with the name SpockConfig.groovy can be placed in the classpath of our test execution or in our USER_HOME/.spock directory. We can also use the Java system property spock.configuration and assign the filename of our Spock configuration file.

Continue reading

Gradle Goodness: Quickly Open Test Report in IntelliJ IDEA

When we execute a Gradle test task in IntelliJ IDEA the IDE test runner is used. This means we can get a nice overview of all tests that have run. If a test is successful we get a green light, otherwise it is red in case of an error or orange in case of a failure. Gradle also generates a nice HTML report when we run the test task. It is placed in the directory build/reports/tests/. IntelliJ IDEA has a button which opens this report when we click on it. The following screenshot shows the button with the tooltip that opens a Gradle test report:

Written with IntelliJ IDEA 14 and Gradle 2.6.

Original article

Spocklight: Include or Exclude Specifications Based On Class or Interface

In a previous post we saw how can use the Spock configuration file to include or exclude specifications based on annotations. Instead of using annotations we can also use classes to include or exclude specifications. For example we could have a base specification class DatabaseSpecification. Other specifications dealing with databases extend this class. To include all these specifications we use the DatabaseSpecification as value for the include property for the test runner configuration.

Because Java (and Groovy) doesn’t support real multiple inheritance this might be a problem if we already have specifications that extends a base class, but the base class cannot be used as filter for the include and exclude runner configuration. Luckily we can also use an interface as the value for the inclusion or exclusion. So we could simple create a marker interface and implement this interface for these specifications we want to include or exclude from the test execution.

Continue reading

Spocklight: Including or Excluding Specifications Based On Annotations

One of the lesser known and documented features of Spock if the external Spock configuration file. In this file we can for example specify which specifications to include or exclude from a test run. We can specify a class name (for example a base specification class, like DatabaseSpec) or an annotation. In this post we see how to use annotations to have some specifications run and others not.

Continue reading

Show Logback Configuration Status with Groovy Configuration

Logback is a SLF4J API implementation for logging messages in Java and Groovy. We can configure Logback with a Groovy configuration file. The file is a Groovy script and allows for a nice an clean way (no XML) to configure Logback. If we want to show the logging configuration and see how Logback is configured we must add a StatusListener implementation in our configuration. The StatusListener implementation prints out the configuration when our application starts. Logback provides a StatusListener for outputting the information to system out or system error streams (OnConsoleStatusListener and OnErrorConsoleStatusListener). If we want to disable any status messages we use the NopStatusListener class.

Continue reading

Redirect Logging Output to Standard Error with Logback

When we use Logback as SLF4J API implementation in our code we can have our logging output send to our console. By default the standard output is used to display the logging output. We can alter the configuration and have the logging output for the console send to standard error. This can be useful when we use a framework that uses the standard output for communication and we still want to see logging from our application on the console. We set the property target for the ConsoleAppender to the value System.err instead of the default System.out.

Continue reading

Gradle Goodness: Using Continuous Build Feature

Gradle introduced the continuous build feature in version 2.5. The feature is still incubating, but we can already use it in our daily development. The continuous build feature means Gradle will not shut down after a task is finished, but keeps running and looks for changes to files to re-run tasks automatically. It applies perfectly for a scenario where we want to re-run the test task while we write our code. With the continuous build feature we start Gradle once with the test task and Gradle will automatically recompile source files and run tests if a source file changes.

Continue reading

Load testing our robots API with Gatling

In a previous blog post we made an API with spray.

Now we’re going to load test it.
For this, we will use http://gatling.io/#/.

In a scala class we can write exactly what and how we want to run the test.
In this test, we will do a post to our API and create a new robot called C3PO.
We will do this 1000 times per second and keep doing this for 10 seconds.
For a total of 10000 C3POs!


If you want to use maven, there is a nice Gatling plugin.
But of course we’d rather use gradle. This works fine too, since we can just run Gatling as a java program.

We can run this test with gradle gatling to get our results.

This is already a pretty neat report. Opening the html file will be even prettier.

Seems like our API can handle 1000 requests/second at least fine. Going higher we’ll have to take some other things into consideration.

  • The amount of connection we can open at once.
  • We’re running both the API and gatling on the same machine now.
  • If we run it on another machine, the network may become the bottleneck
  • Gatling may be the bottleneck.

You can find the whole source here.

Options with flatMap

Suppose I have a List of things on which I want to do something that may fail.
In this example I have a List of Strings that I want to turn into a List of Integers.

The problem is that some of the strings can’t be parsed. And I don’t know which, until I try to parse them. So it’s impossible to filter them out beforehand.
flatMap comes to the rescue!

Because we’re flatMapping over a List, it’s normal to return a List.
If we look at the documentation we can return a lot more.

So we can write the code in a clearer way with Option.