We live in a fast-paced world where a standard project delivery strategy is agile or it is a direction which people tend to follow. If you have been part of an agile software delivery practice then somewhere in your coding career you have met with some form of tests. Whether they might be unit or integration ( system ) or some form of E2E test.
You might be familiar with the testing pyramid and with the benefits and scopes of the different types of tests presented in the pyramid.
Let’s take a quick look at the pyramid:
Unit
As shown on the image above tests that we write are grouped into layers from which the pyramid is built. The foundation layer which is the biggest. It shows us their quantity. Meaning we need more of them on our application. They are also called Unit Tests because of the scope which they are testing. A small unit e.g. an if clause.
Integration/System
The tests belonging to the middle layer are called Integration tests and their purpose is to test integration between one or more elements inside an application and in quantitative representation we need fewer tests of this type than Unit tests.
UI/E2E
The last layer is the smallest one meaning that the quantity of those tests should be the smallest. Those types of tests are also called UI or E2E tests. Here a test has the biggest scope meaning that it is checking more interconnected parts of your application i.e whole register scenario from UI perspective.
As we go from the bottom to the top costs for maintenance are increasing, respectively their speed is decreasing. Confidence is also a crucial part. If a test higher in the pyramid passes we are more confident that our application works or some part of it at least.
Our focus is on the middle layer. So-called Integration tests lay there. As we mentioned above those are the tests that check the interconnection between one or more modules inside an application e.g tests which check that a user can be registered by pinging an endpoint. The scope of this test is to prepare data, send a request to the corresponding endpoint and also check whether the user has been successfully created in the underlying datastore. Testing integration between controller and repository layer, therefore, their name “An integration test”.
In my opinion, I think that tests are a must-have for every application.
Therefore we are writing integration tests for asynchronous code.
With multi-threaded data processing systems and increased popularity of reactive programming in Java, we are puzzled with writing proficient tests for asynchronous code.
Writing high-value tests is hard, but writing high-value tests for asynchronous code is harder.
Problem
Let’s take a look at this example where we have a small system that exposes several endpoints for updating a person. We have created several tests each is updating a person with different names. When a test is running it tries to update a person by sending a request via an endpoint. The system receives the request and returns ok status. In the meantime, it spans a different thread for the actual person update. On the side of the tests, we don’t know how much time does it gonna take for the update to happen so the naive approach is to wait for a specific time after which we are going to verify whether the actual update has happened.
We have several tests which ping a different endpoint. The endpoints are differing in the wait time that would be needed to process each requestupdatePersonWith1SecondDelayupdatePersonWith2SecondDelayupdatePersonWith3SecondDelayupdatePersonWithDelayFrom1To5Seconds
In order for our tests to pass, I used the naive approach by adding a function waitForCompetition() which is nothing else than some sleep of the test thread. Thread.sleep() in Java.
Example
The first execution of tests with a timeout of 1 second. The total execution is 4 seconds but not all tests have passed.
The second execution of tests with a timeout of 3 seconds. The total execution is 12 seconds but not all tests have passed.
Third execution of tests with a timeout of 5 seconds. The total execution is 20 seconds where all tests have passed.
But in order for all the tests to pass, we would need a max of 5-second sleep wait which is executed after each test. This way we are guaranteeing that every test will pass. However, we add an unnecessary wait of 4 seconds for the first test and respectively add wait time for other tests. This results increased execution time, hence optimum wait time is not guaranteed.
Solution
As stated in the official documentation Awaitility is a small java library for synchronizing asynchronous operation. Which helps expressing expectations in a concise and easy to read manner. Which is a smart option for checking the outcome of some async operation.
It’s fairly easy to incorporate this library into your codebase.
You just need to add the library into pom.xml:
<dependency>
<groupId>org.awaitility</groupId>
<artifactId>awaitility</artifactId>
<version>3.0.0</version>
<scope>test</scope>
</dependency>
And add the import in your test:import static org.awaitility.Awaitility.await;
Let’s take a look at an example before using this library:
@Test
public void testDelay1Second() throws Exception {
Person person = new Person();
person.setName("Yara");
person.setAddress("New York");
person.setAge("23");
personRepository.save(person);
ObjectMapper mapper = new ObjectMapper();
person.setName("Daenerys");
this.mockMvc.perform(put("/api/endpoint1/" + person.getId())
.contentType(APPLICATION_JSON)
.content(mapper.writeValueAsBytes(person)))
.andExpect(status().isOk())
.andExpect(content().string(containsString("Request received")));
waitForCompletion();
assertThat(personRepository.findById(person.getId()).get().getName())
.isEqualTo("Daenerys");
}
An example with Awaitility:
@Test
public void testDelay1Second() throws Exception {
Person person = new Person();
person.setName("Yara");
person.setAddress("New York");
person.setAge("23");
personRepository.save(person);
ObjectMapper mapper = new ObjectMapper();
person.setName("Daenerys");
this.mockMvc.perform(put("/api/endpoint1/" + person.getId())
.contentType(APPLICATION_JSON)
.content(mapper.writeValueAsBytes(person)))
.andExpect(status().isOk())
.andExpect(content().string(containsString("Request received")));
await().atMost(Duration.FIVE_SECONDS).untilAsserted(() -> assertThat(personRepository.findById(person.getId()).get().getName())
.isEqualTo("Daenerys"));
}
Example of the executed test suite with the library:
As we can see the execution time is greatly reduced from 20 seconds for all tests to pass in just under 10 seconds.
As you can spot the function waitForCompletition() is removed and a new wait is introduced from the library as await().atMost(Duration.FIVE_SECONDS).untilAsserted()
You can also configure the library using static methods from the Awaitility class:Awaitility.setDefaultPollInterval(10, TimeUnit.MILLISECONDS);Awaitility.setDefaultPollDelay(Duration.ZERO);Awaitility.setDefaultTimeout(Duration.ONE_MINUTE);
Conclusion
In this article, we have taken a look at how to improve tests when dealing with asynchronous code using an interesting library. I hope this post helps benefit you and adds to your knowledge. You can find a working example with all of the tests with and without the Awaitility library on this repository.
Also, you can find more about the library here.
