Skip to main content

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation.

If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon.

Instalation 

If you are an maven user, add following dependency:

<dependency> 
    <groupId>com.anotherchrisberry</groupId> 
    <artifactId>spock-retry</artifactId> 
    <version>0.6.2</version> 
    <type>pom</type> 
</dependency>

For gradle users:

compile 'com.anotherchrisberry:spock-retry:0.6.2'

Note that Spock-Retry is available from Bintray so you may have to add jcenter repository to your build definition.

Usage 

As I’ve already said, library is pretty straightforward, as well as the usage is. Lets have a look at basic example, where we have a single Spock’s test case that occasionally may fail with false-positive result. We want to rerun it once on every failure:


What’s important here is the @RetryOnFailure annotation. It tells that If your test fails, it’ll be rerun once. You can specify the number of retry attempts by adding the times parameter. What’s more, you can define a delay time between one retry and another:


Spock-Retry supports also annotating tests on test class level. If you do so, only failed tests will be rerun, not a whole test class. You can also combine @RetryOnFailure annotation and Spock’s @Stepwise – in this case also only failed steps will be rerun.

If you want to annotate your whole test suite with @RetryOnFailure, you don’t have to put in in every class individually. In most cases Spock’s Specification class is extended with custom specifications. You can annotate your custom specification class, and RetryOnFailure will work in every test class that extends it:


If you have whole test suite were 1 rerun is just fine, but there is this one test that’s more flaky than others, you can also annotate whole suite in custom specification class, and then additionally put retry annotation with different configuration on this problematic test class.

Summary 

Flaky tests are nothing new. The problem has been around for a while and there’re no simple solution – automatic reruns isn’t one. Although having longer test-run times (due to reruns) is still better than false-positive tests.

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous...

REST API mocking with Wiremock

Probably every developer or tester have used mocks at least once in their daily professional work. Functionality mocking is an excellent way to improve development process of integrated systems production, or testing heavy dependent application functionalities. With the growth of popularity of REST webservices, API mocking is becoming hot topic. In this article I would like to introduce a simple getting-started tutorial of setting basic standalone REST API mock server with Wiremock on your local machine. Wiremock is a simple library written in Java for mocking web services. Installation  To run standalone wiremock server, download jar from here and run: $ java -jar wiremock-1.55-standalone.jar you should see: This means that wiremock has started an empty mock server on localhost on port 8080. After you navigate to http://localhost:8080/__admin/ in your browser, you should get empty mappings entity: You can also change default port by adding --port...