Unit Test with BDDMockito
In application development, you will often encounter bugs or errors in some processes. To avoid many bugs, we must do a test in our application. Application testing is mandatory because the importance of application testing will determine the quality of the application. One of the methods for testing the applications is to create unit tests. The unit test is a level of software testing where individual units or components of a software are tests. Unit tests help developers to determine whether the implemented function or feature is following the defined design. There are several advantages to making unit tests. It is easier to find errors or bugs caused by other developers who changed our code. And, you do not need to run the program while providing some input to test whether the program will run as you expected.
In Spring, you can create a unit test using BDDMockito. Behavior-Driven Development (BDD) encourages writing tests in a natural, human-readable language that focuses on the behavior of the application to help you make your unit test readable and easy to understand, not only by you but with others developers too. BDDMockito is a part of a Mockito where Mockito is an open-source mocking framework for unit tests written in Java. You can also use it with JUnit to create and use mock objects during unit testing. To write unit tests with BDDMockito, we can use the Given-When-Then pattern. Given-When-Then is a style of representing tests to specify a system behavior.
The essential idea is to break down writing a scenario (or test) into three sections:
- The given part describes the state of the world before you begin the behavior you are specifying in this scenario, like what other methods are going to return so that you can control the test behavior. You can think of it as the pre-conditions to the test.
- The when is that behavior that you are specifying.
- Finally, the then section describes behavior you expect due to the specified behavior that you describe in the given part, like whether the method you are testing is executing some other method once or twice or not, etc.
To get started, we need to add maven dependency in pom.xml:
And then include the following static import so we can use BDDMockito:
In this case, I will make an example of a tea maker service. In this service, we are allowed to make tea with three different types, three different levels of sugar, and ice quantities. Every time we try to make tea, we need to define those three arguments. Otherwise, the service will return a result containing an error message and no tea. If we supplied those three arguments, we need to check whether the stock for that tea type is available or not. If the tea is available, then we must update the stock amount for that type. If it is not available, then the service will return a result containing an error message and no tea, but in this case, we need to make sure that we must not update the stock for that tea type. Below are the implementation code, this example service, repository, and models.
- Test case 1:
In this test case, we are going to check whether the service will return a result containing “Please specify the tea type!” as the error message and no tea because we do not specify the tea type that we want to make.
- Test case 2:
In this test case, we are going to make green tea with less sugar and ice. We are expecting a result containing “GREEN_TEA is not available” as the error message and no tea. In this test case, we are going to describe the behavior of the mocked tea repository for the getTeaStock method using given, so that the getTeaStock can return an empty stock of green tea. Because the stock amount is not available, we also expect that the service will never update the tea stock value in the repository using verify.
- Test case 3:
In this test case, we are going to make green tea with less sugar and ice. We are expecting a result containing no error message and a green tea with less sugar and ice. In this test case, we are going to describe the behavior of the mocked tea repository for the getTeaStock method, so that the getTeaStock can return a non-empty stock of green tea using given. Because the stock amount is available, then the tea is successfully created. We also expect that the service will update the tea stock value in the repository using verify.
Using this pattern, we can make our test case more readable. But remember that when we are using the given and verify method, we must pass a mocked object. Otherwise, it will not work. Also, when we are creating a unit test, we must not only focus on the coverage, we must focus on the real-world test case instead. Because we can easily achieve high cover, but it does not indicate that we already define all the possible test cases.
Thank you.
References:
