Testing Asynchronous Operations in Spring With JUnit and Byteman
Testing Asynchronous Operations in Spring With JUnit and Byteman
Learn how to test such operations in an application that uses spring context (with asynchronous operations enabled).
Join the DZone community and get the full member experience.Join For Free
Testing asynchronous operations might cause some troubles and usually requires few challenges and also code changes (even in production code).
In this article, we can find how to test such operations in an application that uses spring context (with asynchronous operations enabled). We don’t have to change the production code to achieve this.
Tests are going to be run in JUnit 4. For tests, we are going to use features from the Byteman library. We also gone have to attach the “Bmunit-extension” library, which gives contains JUnit rule and some helper methods used during our tests.
Byteman is a tool that injects Java code into your application methods or into Java runtime methods without the need for you to recompile, repackage, or even redeploy your application.
You may also like: Using Byteman to Find Out Why the TimeZone Changed on a Java App Server
The Bmunit-extension is a small project on GitHub, which contains junit4 rule, which allows integration with the Byteman framework and uses it in JUnit and Spock tests. And It contains a few helper methods.
In this article, we are going to use code from the demo application, which is part of the “Bmunit-extension” project. Source code can be found on https://github.com/starnowski/bmunit-extension/tree/feature/article_examples.
Tests case assumes that we register a new application user (all transactions were committed) and sends an email message to him. The email message sending operation is asynchronous.
Now the application contains few tests which show how this case can be tested.
There is no suggestion that the code implemented in the demo application for the Bmunit-extension is the only approach and even the best one. The primary purpose of this project is to show how such a case could be tested without any production code change with usage of the Byteman library.
In our example test, we would like to check the process of a new application user registration process. Let’s assume that the application allows user registration via Rest API. So Rest API client sends a request with user data. The Rest API controller is proceeding the request. After when the database, transaction is being committed, but before returning Rest API response, the controller invokes an Asynchronous Executor to send an email to a user with a registration link (to confirm email address).
The whole process is presented in the sequence diagram below.
Now I am guessing that this might not be the best approach to register users. Probably better would be to use some kind of scheduler component, which checks if there is an email to send. Not to mention that for larger applications, the separate microservice would be more suitable. Let’s assume that for an application that does not have a problem with available threads is okay.
Implementation contains Rest Controller:
Service which handles “User” object:
A service which handles mail messages:
To see how to attach all Byteman and Bmunit-extension dependencies, please check the section "How to attach project".
Let’s go to test code:
Test class needs to contain an object of type “BMUnitMethodRule” (line 13) to load Byteman rules.
The BMRule annotation is part of the BMUnit project. All options “name”, “targetClass“ (line 28), “targetMethod“ (line 29), “targetLocation“ (line 30) and “action“ (line 31) refers to the specific section in Byteman rule language section. Options “targetClass“, “targetMethod“ and “targetLocation“ are used to a specified point in java code, after which the rule should be executed.
The “action” option defines what should be done after reaching the rule point.
If you would like to know more about the Byteman rule language, then please check Programer’s guide.
The purpose of this test method is to confirm that the new application user can be registered via the rest API controller, and the application sends an email to the user with registration details. The last important thing, the test confirms that the method which triggers an Asynchronous Executor which sends an email is being triggered.
To do that, we need to use a “Joiner” mechanism. From “Developer Guide” for Byteman, we can find out that the joiners are useful in situations where it is necessary to ensure that a thread does not proceed until one or more related threads have exited.
Generally, when we create joiner, we need to specify the identification and number of thread which needs to join. In the “given” (line 34) section we executes “BMUnitUtils#createJoin(Object, int)” to create “UserControllerTest.shouldCreateNewUserAndSendMailMessageInAsyncOperation” joiner with one as expected number of threads. We expect that the thread responsible for sending is going to join.
To achieve this, we need to via BMRule annotation set that after method exit (“targetLocation” option with value “AT EXIT”) the specific action need be done which executes method “Helper#joinEnlist(Object key)”, this method does not suspend current thread in which it was called.
In the “when” section (line 41), besides executing testes method, we invoke “BMUnitUtils#joinWait(Object, int, long)” to suspend test thread to wait until the number of joined threads for joiner “UserControllerTest.shouldCreateNewUserAndSendMailMessageInAsyncOperation” reach expected value. In case when there won’t be expected number of joined threads, then execution is going to reach a timeout, and certain exceptions is going to be thrown.
In the “then” (line 45) section, we check if the user was created, and email with correct content was sent.
This test could be done without changing source code thanks to Byteman.
It also could be done with basic java mechanism, but it would also require changes in source code.
First, we have to create a component with “CountDownLatch”.
There are also changes required in “MailService” so that the specific methods for type DummyApplicationCountDownLatch would be executed.
After applying those changes we can implement below test class:
The Byteman allows for testing asynchronous operations in an application without changing its source code. The same test cases can be tested without the Byteman, but it would require changes in source code.
Opinions expressed by DZone contributors are their own.