Geb Gems: Handling AJAX requests

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:

First we change our baseUrl in the GebConfig.groovy file to the w3school site:

Second we define the W3schools page with the needed content and the makeRequest method which clicks the button.

The key statement here is the waitFor line. This will wait till the condition in the closure returns true. The waitFor uses the default timeout configuration which is for Geb 5 seconds.

Next we’re going to make our test which verifies our content has been updated.

When you run the now run the test, the test will succesfully verify the updated content of the w3schools website.

Done with Groovy 2.4.3

NextBuild 2015 Conference Report

Saturday May 30th was the first NextBuild developer’s conference in Eindhoven at the High Tech Campus. The conference is free for attendees and offers a variety of subjects presented by colleague developer’s. This meant all talks were very practical and covered subjects encountered in real projects. This adds real value for me to attend a talk. Although it was on a weekend day there were about 150 attendees present. The location was very nice and allowed for a nice, informal atmosphere with a lot of opportunities to catch up.

Continue reading

Validating input in Spray

In Spray, you get a lot of input validations for free. If you have a model like this:

See here for the whole example.

All the attributes are required. So if you try to post a robot without a name.

You’ll get http 400 with this message:

The types are also checked.


It is possible to make a value optional with Option.

And we can add extra requirements with ‘require’. In the second parameter we can write a nice readable message.

Now when we post an impossible robot.

We get a nice error message.

This way you can make as complex and informative as you want.

Groovy Goodness: Share Data in Concurrent Environment with Dataflow Variables

To work with data in a concurrent environment can be complex. Groovy includes GPars, yes we don’t have to download any dependencies, to provide some models to work easily with data in a concurrent environment. In this blog post we are going to look at an example where we use dataflow variables to exchange data between concurrent tasks. In a dataflow algorithm we define certain functions or tasks that have an input and output. A task is started when the input is available for the task. So instead of defining an imperative sequence of tasks that need to be executed, we define a series of tasks that will start executing when their input is available. And the nice thing is that each of these tasks are independent and can run in parallel if needed.
The data that is shared between tasks is stored in dataflow variables. The value of a dataflow variable can only be set once, but it can be read multiple times. When a task wants to read the value, but it is not yet available, the task will wait for the value in a non-blocking way.

Continue reading

Grails Goodness: Custom Data Binding with @DataBinding Annotation

Grails has a data binding mechanism that will convert request parameters to properties of an object of different types. We can customize the default data binding in different ways. One of them is using the @DataBinding annotation. We use a closure as argument for the annotation in which we must return the converted value. We get two arguments, the first is the object the data binding is applied to and the second is the source with all original values of type SimpleMapDataBindingSource. The source could for example be a map like structure or the parameters of a request object.

Continue reading

Geb Gems: Using Pages and Modules

In the previous blog post about Geb, we have been introduced to the Geb Framework. In this blogpost we will be introduced to Pages and Modules. A Page represents a specific page from a web application. A module represent a part of the page; for example a sign-up form, a menu bar or contact form. Pages and Modules are very useful since they are very easy to reuse and therefore useful to create more advanced UI tests.

In this blogpost we are going to use Pages and Modules to test the contact form of the JDriven website. We will verify that a success message will appear if we submit a valid form.

Pages have a url attribute which represent the address to the page. To get the complete url, Geb requires a baseUrl which we can define in the GebConfig.groovy

Since the contact form has a select form tag, we require an extra jar as Selenium dependency to handle select tags. Therefore we add the following dependency to our pom.xml.

Next step is to define our ContactPage which extends from geb.Page. The static at attribute represents the condition for Geb to verify the browser is at the defined page.

The static url string represents the suffix which will be added to the baseUrl to navigate to the Contact page.

In the static closure content block we define our content which is on the Contact page. For the JDriven website we define for now the header and the contact form. As you can see there is a reference to the the ContactFormModule which is defined below. The mechanism to define module content is the similar to the way we define page content.

Next step is to create our test class which is done below.

As we can see creating Pages and Modules in Geb is very easy and straightforward. The huge benefit we have now, is that we can easily reuse pages and modules in other tests.

Written with Groovy 2.4.3.

Grails Goodness: Adding Health Check Indicators

With Grails 3 we also get Spring Boot Actuator. We can use Spring Boot Actuator to add some production-ready features for monitoring and managing our Grails application. One of the features is the addition of some endpoints with information about our application. By default we already have a /health endpoint when we start a Grails (3+) application. It gives back a JSON response with status UP. Let’s expand this endpoint and add a disk space, database and url health check indicator.

Continue reading

Grails Goodness: Log Startup Info

We can let Grails log some extra information when the application starts. Like the process ID (PID) of the application and on which machine the application starts. And the time needed to start the application. The GrailsApp class has a property logStartupInfo which is true by default. If the property is true than some extra lines are logged at INFO and DEBUG level of the logger of our Application class.

Continue reading

Grails Goodness: Save Application PID in File

Since Grails 3 we can borrow a lot of the Spring Boot features in our applications. If we look in our Application.groovy file that is created when we create a new Grails application we see the class GrailsApp. This class extends SpringApplication so we can use all the methods and properties of SpringApplication in our Grails application. Spring Boot and Grails comes with the class ApplicationPidFileWriter in the package org.springframework.boot.actuate.system. This class saves the application PID (Process ID) in a file when the application starts.

Continue reading

Awesome Asciidoctor: Display Keyboard Shortcuts

When we want to explain in our documentation which keys a user must press to get to a function we can use the keyboard macro in Asciidoctor. The macro will output the key nicely formatted as a real key on the keyboard. The syntax of the macro is kbd:[key]. To get the desired output we must set the document attribute experimental otherwise the macro is not used.

Continue reading