Last updated: 2024-04-26
Using REST Assured for Spring Boot tests
REST Assured has been in use for quite some time for testing Spring Boot projects and still does this job perfectly. What advantages does this library provide and how can we use it in our project?
The setup for integration tests with Spring Boot has been described already. So here we can go into more detail about the library itself.
Spring Boot setup for REST Assured
For an integration test, we start our entire Spring Boot application so that we can call our REST API properly from the outside. This allows us to verify the functioning of our application at a very high level. First, we add the required dependencies to our build.gradle
or pom.xml
.
Required dependencies in a Maven application
Since rest-assured
is included in Spring Boot Dependency Management, we do not need to specify a version - the recommended version is selected automatically. Specifying the test dependencies in Gradle looks like this:
Required dependencies in a Gradle application
Many helpers are available with spring-boot-starter-test
, which we use straight away. Let's define an abstract class that we can use later for the actual tests.
Abstract base class for our integration tests
With @SpringBootTest
we start the entire Spring Boot app on a random port, which is also stored in the field annotated with @LocalServerPort
. In the initRestAssured
method, we define a few useful settings for REST Assured:
- the current port is written to the
port
field so that we can use relative paths in our tests - URL encoding is deactivated - it is usually not needed and tends to cause problems
- we log all the errors when a test fails
We are now ready to create an actual test class.
Using REST Assured
The following class implements our abstract class and thus inherits its entire setup. For simplicity, we assume that our application has an endpoint/api/products/
that returns two products as a list.
Testing our product endpoint
The fluent API is always called in up to three steps: First, we define the prerequisites such as headers or additional parameters in the given()
block. The actual endpoint is invoked within the when()
block - here the call to our REST API with a GET request. In then()
we validate whether the result meets our expectations. In our example, we check the status code and certain properties of the JSON response.
We could also get back the full response of our API with .extract().body()
and process it further. Via .extract().sessionId()
we get back the session ID, which we could reuse in the given()
block of a subsequent request. REST Assured provides many useful helpers and at the same time, as a developer, you know directly what is happening.
Form login with REST Assured
Sometimes a REST API is also protected by a form login, e.g. if a Thymeleaf frontend is coming together with an endpoint for AJAX calls. For authentication, we can call the /login
endpoint of Spring Security directly. With the csrf(...)
method, REST Assured will execute a GET request first, read the "_csrf"
field and provides its value to the actual login.
Extension of the BaseIT class for the form login
We can then integrate the new method in our tests using .sessionId(authenticatedSession())
so that the API call is executed using an authenticated user.
Conclusion
REST Assured is still a modern way of testing Spring Boot applications. It simulates a real call from the outside - with MockMvc
, for example, the tests can be limited if a certain state is simply assumed (mocked).
In the Professional plan, Bootify can generate the integration tests for the REST API of your Spring Boot application. The entire setup described - and much more - is thus available in just a few moments.
See Pricing
or read quickstart