How to fast generate your API Test with OpenAPI Tools and Rest-Assured by Elias Nogueira

The creation of API Test Automation using Java and Rest-Assured might be boring because it always follows the same repeated pattern: creating the code to make the HTTP requests, the model classes used in the responses, the object mapping, and the tests.

With the usage of the OpenAPI Tools, we can quickly generate the client code and the test stubs, speeding up the development process.

You will also learn the possible problems during its adoption that can add more maintenance effort and how to solve it with abstractions.

Approaches You will learn how to use an OpenAPI specification to automatically generate the client code to use in your test, as we will call it basic usage. As the first improvement, you will learn how to use templates and automatically create custom client and test code. And as the ultimate improvement, you will learn how to decrease the maintenance and focus on a more business-driven development by creating abstractions on top of the client code. Everything will be hands-on.

Tools

Java 17 as a programming language
Rest-Assured as the API automation library
JUnit 5 as the testing support tool
Maven as a build and dependency management tool
Takeaways

Learn how to speed up the API test automation code
Learn how to better organize the API test framework by the application of abstraction
Have a concrete example that can be easily applied at work in any context

Elias Nogueira, Backbase

Recorded at Jfokus 2023 in Stockholm 7th of february

[RalphMarkham]

thank you ... boring ... lol ... always appreciate a well thought out, simple solutions for complicated problems ...

[mathiaskeulen]

Great presentation, one remark at 38:30; I prefer the given when then syntax, you probably do not prefer that syntax because you are well informed as to what is behind all of the abstracted code. That's also the major criticism of people surrounding Gherkin right? It is tedious. However, the entire point of Gherkin is that it's easy for those who are NOT in the matter, so that they can easily see what's going to happen (is supposed to happen) as a user in that scenario. You already know what's going on, but software teams change regularly and we often switch around the teams so that knowledge sharing is needed as efficiently as possible.
So the ideal way would be to have the abstraction inside your steps in my opinion, so that it's still readable to those who are not in the matter.

[Sweetbabyjmar]

Excellent presentation, thank you.
At the end he mentions another presentation he is doing "tomorrow", where would I be able to find that video?

[tricepsbrachii]

Why should you download the API-spec? Are you not testing your own API?

[АнтонФиличкин-ли]

Good example on how to generate an API client from Open API spec. 🚫BUT is so wrong in so many ways regarding RestAssured... Really :). The power of RestAssured is the Response and Request specifications, they make validations clear, fluent and reusable! And here we are hiding the RestAssured response and returning DTOs - effectively dropping all the benefits RestAssured provides. Creating a bunch of layers just to end with direct asserts on body fields? How it is more effective? Why even bother with RestAssured here at all? Just generate ANY client supported by Open API generator here - the result is going to be the same. You need mapping from the box? It's a Java in 2023 it means you are already using Spring/SpringBoot. And you are not forced to use static RestAssured methods at all. 😉