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.

The external Spock configuration file is actually a Groovy script file. We must specify a runner method with a closure argument where we configure basically the test runner. To include specification classes or methods with a certain annotation applied to them we configure the include property of the test runner. To exclude a class or method we use the exclude property. Because the configuration file is a Groovy script we can use everything Groovy has to offer, like conditional statements, println statements and more.

Continue reading →

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.

In the following example configuration file we define the status listener with the statusListener method. We use the OnConsoleStatusListener in our example:

Continue reading →

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. The following sample Logback configuration in Groovy send the logging output to the console and standard error:

appender("SystemErr", ConsoleAppender) {
    // Enable coloured output.
    withJansi = true

    encoder(PatternLayoutEncoder) {
        pattern = "%blue(%-5level) %green(%logger{35}) - %msg %n"
    }

    // Redirect output to the System.err.
    target = 'System.err'

}

root(DEBUG, ["SystemErr"])

Continue reading →

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.

To use the continuous build feature we must use the command line option --continuous or the shorter version -t. With this option Gradle will start up in continuous mode. To stop Gradle we must use the Ctrl+D key combination.

Continue reading →

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! RobotsLoadTest.scala:

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class RobotsLoadTest extends Simulation {
	val baseUrl = "http://localhost:8080" //We need to have our API running here

	val httpProtocol = http
		.baseURL(baseUrl)
		.inferHtmlResources()
		.acceptEncodingHeader("gzip,deflate")
		.contentTypeHeader("application/json")
		.userAgentHeader("Apache-HttpClient/4.1.1 (java 1.5)")

	val s = scenario("Simulation")
		.exec(http("request_0")
		.post("/robots")
		.body(StringBody("""{
						|  "name": "C3PO",
						|  "amountOfArms": 2
						|}""".stripMargin))
		)

	setUp(s.inject(constantUsersPerSec(1000) during(10 seconds))).protocols(httpProtocol)
}

Continue reading →

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.

val strings = List("1", "bla", "4")

Continue reading →

In a previous blog I wrote how to make an API. See here.
Now we'll make a client to use that API. This can be done with spray-client. First we add dependencies for spray-client and spray-json:

apply plugin: 'scala'

version = '1.0'

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'org.scala-lang', name: 'scala-library', version: '2.11.6'
    compile group: 'com.typesafe.akka', name: 'akka-actor_2.11', version: '2.3.9'
    compile group: 'com.typesafe.akka', name: 'akka-remote_2.11', version: '2.3.9'
    testCompile group: 'org.scalatest', name: 'scalatest_2.11', version: '2.2.4'
    compile group: 'io.spray', name: 'spray-http_2.11', version: '1.3.3'
    compile group: 'io.spray', name: 'spray-httpx_2.11', version: '1.3.3'
    compile group: 'io.spray', name: 'spray-json_2.11', version: '1.3.1'
    compile group: 'io.spray', name: 'spray-client_2.11', version: '1.3.3'
}

Continue reading →

Tuesday we had our second ever "Vrolijke Framboos" (Dutch for Happy Raspberry) Java code challenge at JDriven and it was a blast! This year’s challenge was to create a REST service client that would play a number guessing game with the server. After setting up a session you would guess a number and the server would respond with either "lower", "higher" or "bingo". The goal was to guess as many numbers in the two minutes you’d be given. Given the name of the challenge you can probably guess that the target platform would be a Raspberry Pi!

It was an incredible and fun experience and in this post I want to explain how I approached the challenge and how my solution ended up in the second place, making me just miss the opportunity to take home the trophy and a new Raspberry.

Continue reading →

As we all know Javascript gives us the awesome ability to create functions inside functions. This allows us to create private functions which support the main function. It is also something we do often when creating object functions. This structure is used by angular for the creation of providers and directives alike. Every once in a while I personally come to a point where I would like to test these private functions. This is especially true for use cases in Angular such as directives.I'd like to be able to run unit tests for a directive's private functions, but I'd like to do this without having to make them public. The way I do this is by using a concept called reflection. This process actually described by Bob Gravelle in his post 'Accessing Private functions in Javascript' actually exposes the private functions by using the toString method of a function. Before I go into specifics let me say that this article should only be used as an approach  for unit testing. There is a good reason for keeping private functions private and using this concept for application code may very well introduce interesting side effects. That being said let's go into details. In order for us to use this concept we'll need to make some slight changes to our directive. Normally we would declare our Directive Definition Object (DDO) and directly return it. As below:

return {
  restrict: 'E'
  ...
}

Continue reading →

One of the biggest struggles while testing web applications that use AJAX is dealing with the timing issues caused by asynchronous nature of the request. A common solution is using timeouts to wait for the AJAX call to be completed. This could cause lots of timing issues. Using Geb there is a better way to determine that the AJAX call and its callback has been completed.

In this blog post we will test the W3Schools website which has a button on it which executes an AJAX request: http://www.w3schools.com/ajax/ajax_example.asp

Continue reading →