CODEWITHSUNDEEP
javajunitjerseymockito
Silencer310
Silencer310

Reputation: 1090

Testing a java jersey application

I have a java/jersey api that is called from the front end. I need to write tests for the java code. How the code is written is: 1. The api call executes the resource method, this calls a separate method that gets data from db and returns to the resource method. This then returns a javax.ws.rs.core.Response to the client.

This is going to be my first time writing tests, so please answer considering I know nothing. What is the best way to start here? And what types of tests should I write. Unit tests are what I’m aiming for here.

Now I have done a lot of research here and I’m leaning towards using JUnit + Mockito to do this. But how do I check for the data in a Response object?

And how should I check the other file that is getting data from db? I found out DBUnit that can do that, but do I need it?

Another framework I came across was Rest Assured. Do I need to include that also? Or can the same things be done with JUnit/Mockito?

I just want some direction from people who have tested out jersey api’s. And want to know what is the most common way to do this.

Upvotes: 0

Views: 269

Answers (1)

Loïc Le Doyen
Loïc Le Doyen

Reputation: 1055

I do not think there is a best way to do this, what you need to test is often subjective and dependent on the context.

However, you can structure your code in a way that the most important is tested easily and what's left (integration) can be done later / with different tools.

What I suggest here is to follow the principles of the hexagonal architecture. The idea is to keep at the center of your application and without any kind of dependencies (imports ...) to any framework (jaxrs, jpa, etc.) all business rules. These rules can be easily designed with TDD. You will then have very short running tests. It may be necessary to use Mockito to mock implementations of SPI interfaces.

In a second time, you can use this "core" by wiring adapters to the outer world (HTTP, databases, AMQP, etc.), using API and implementing SPI interfaces.

If you want to test these adapters, you exit the scope of unit-tests, and write integration-tests. Integration with a framework, a protocol, anything really. This kind of tests can use a wide variety of tools, from a framework-related mock (like Jersey test framework), in-memory database (like H2), to fully operational middleware instance using tools like testcontainers.

What is important to remember when writing integration-tests is they are slow in regards of unit-tests. In order to keep a feedback-loop as short as possible, you will want to limit the number of integration-tests to a minimum.

Hoping this will help you!

Upvotes: 2

Related Questions