Spocklight: Set Timeout On Specification Methods

When we write a feature method in our Spock specification to test our class we might run into long running methods that are invoked. We can specify a maximum time we want to wait for a method. If the time spent by the method is more than the maximum time our feature method must fail. Spock has the @Timeout annotation to define this. We can apply the annotation to our specification or to feature methods in the specification. We specify the timeout value as argument for the @Timeout annotation. Seconds are the default time unit that is used. If we want to specify a different time unit we can use the annotation argument unit and use constants from java.util.concurrent.TimeUnit to set a value.

Continue reading

Spocklight: Ignoring Other Feature Methods Using @IgnoreRest

To ignore feature methods in our Spock specification we can use the annotation @Ignore. Any feature method or specification with this annotation is not invoked when we run a specification. With the annotation @IgnoreRest we indicate that feature methods that do not have this annotation must be ignored. So any method with the annotation is invoked, but the ones without aren’t. This annotation can only be applied to methods and not to a specification class.

Continue reading

Unit testing an AngularJS directive’s private functions.

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. 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.

Nifty JUnit : Using Rule on Method and Class level

As shown in a the post Nifty JUnit : Working with temporary files, it is possible to use @Rule in a JUnit test, which is a Method level Rule. In this example I would like to show the variation of the @ClassRule for a Class level Rule.

Method Rule

The @Rule is fired before each test method (just like @Before) and after each test method (just like @After) of the test class, as shown in the example below.

Class Rule

Besides the regular @Rule we have the possibility to create a @ClassRule. In the example of the TemporaryFolder it will result in a folder which is created before all test methods (just like @BeforeClass) and destroyed after all test methods (just like @AfterClass). In the example below you can create a temporary file and use the exact same file in all the test methods. The temporary file will be deleted when all the test methods are finished.

Nifty JUnit : Working with temporary files

I get this question quite often and I struggled with it many times before: How do I work with temporary files in my JUnit testcases? I would like to explain two simple ways of working with temporary files in JUnit.

1. DeleteOnExit

Create a temporary file with the Java File API and mark it directly as deleteOnExit(). The created file will be deleted when the JVM exits.

2. TemporaryFolder Rule

Use the TemporaryFolder as a Rule in your JUnit Test. TemporaryFolder is an existing Rule from JUnit, see documentation here. The Rule will fire a create() before each test method, which creates a temporary directory. After each test method a delete() method is fired, which deletes the folder and all created files recursively.

Integration testing on REST urls with Spring Boot

We are building a Spring Boot application with a REST interface and at some point we wanted to test our REST interface, and if possible, integrate this testing with our regular unit tests. One way of doing this, would be to @Autowire our REST controllers and call our endpoints using that. However, this won’t give full converage, since it will skip things like JSON deserialisation and global exception handling. So the ideal situation for us would be to start our application when the unit test start, and close it again, after the last unit test.
It just so happens that Spring Boot does this all for us with one annotation: @IntegrationTest.
Here is an example implementation of an abstract class you can use for your unit-tests which will automatically start the application prior to starting your unit tests, caching it, and close it again at the end.

Joy of Coding… and mutation testing in Java

For many years now it has been good practice to write unit tests for your source-code.
And also to use test coverage reporting to see how much of your code is covered by tests.
Although line + branch coverage reporting is quite useful, it doesn’t tell you how good your unit tests actually are. Hence it’s even possibly to achieve 100% coverage without even a single assert in your tests.

Being interested in better ways of testing I attended the “Mutation testing” workshop during this years Joy of Coding conference.
Mutation testing is a radical different approach of executing and analyzing the result and coverage of your unit tests. Instead of measuring how much of your code is “accessed from” your unit tests it determines how much of your code is actually “tested by” your unit tests.

Continue reading