What is the best approach to perform endpoint's unit tests in Quarkus?

Question

I have some doubts regarding the best approach to perform unit tests in Quarkus.

One option is using mocks, but I have a feeling that using mocks I just "make happy" the test coverage plugins, but on real I don't test anything with this approach.

Another option is using a real database, like embedded H2 database, but for this, I need to put the unit test in order (Insert, Get, Update, Delete), sometimes I'll need the inserted ID from another test to perform a delete operation, for example. There are some complex entities that create some difficulty to insert or delete. So, with this approach, I'll lose the concept of a unit test, because I'll lose the tests interdependency.

Does someone have a suggestion for this scenario? Extra information: I'm using liquidbase, panache entity, junity.

Answer 1

Looks like you're looking for integration tests. I would probably go with the next options:

1. Depending on database type, you can either go with in-memory h2, or use testcontainers for external services.
2. Have test startup scripts for sql for general data, insert data directly for small test-cases.
3. Use tools like http://rest-assured.io/ (usually included in initial setup) to do real api calls

In case you really want unit tests, in this case 90% of the time you don't need to have the database to test functionality. Because of decoupling you probably have controllers(resources) separate from services. So in case of unit tests I would probably go with:

1. As stated above split logic from the networking layer, so that any Request handling and wrapping the output to satisfy clients is out of the logic layer. Split the logic itself into smaller chunks if possible, this will eliminate your main concern about complex data
2. For any dependent dependencies, either override them with test beans, or mock them using Mockito. This is especially important for persistency, you need to mock or fake any connection to database, you don't need to test this part because it's handled by libraries usually.
3. You can read JSON objects from files for really complex entities
4. If you really need to have persistency, look at the very first point in this answer.

So it feels like you want to check if your service is doing the job correctly on a higher level, which might not be a unit test, hope the answer will help