3

I'm trying to get my head around unit testing in Jersey.

The classes that do not depend on Jersey directly can be unit tested using standard JUnit. This one is OK.

But there are also Jersey (or, should I say JAX-RS?) dependent classes. In order to test these (inlc. correctness of the annotations, serialization, status codes, etc.) Jersey provides "test framework" that contains base JerseyTest class.

This is also fine and understandable.

Then, however, the official documentation specifies several types of supported containers in which subclasses of JerseyTest can be executed.

It seems like these containers can be divided into two types:

  1. Real containers
  2. In-memory container

From my current (newbie) perspective, all type #1 containers provide the same functionality. Therefore, let's take Grizzly as type #1 representative.

Now, it is clear that in-memory container (which is not a real container at all) is faster than Grizzly. Therefore, I'd like to use this container in order to test Jersey dependent classes. But this statement from the official documentation confuses me:

This containers does not support servlet and other container dependent features, but it is a perfect choice for simple unit tests.

I tried to google for comparison of in-memory container with Grizzly, but did not find any definitive comparison. I also read this highly technical thread, but the downsides of in-memory container are still not clear to me.

In this respect, I have two questions:

  1. What "servlet and other container dependent features" are (no need for a comprehensive list, but just general description)?
  2. If I choose in-memory container, can I then encounter a situation of code that passes test, but fails in production (I will use Tomcat in production, if that matters)?

Thanks

Vasiliy
  • 16,221
  • 11
  • 71
  • 127

1 Answers1

2

What "servlet and other container dependent features" are (no need for a comprehensive list, but just general description)?

Say you need to use HttpServletRequest, ServletContext, etc. in your resources. Or if you are using serlvet filters or listeners that affect the Jersey application. These are servlet features.

Other "container features" just means any other features that are specific to that container you are using in production. For example, with Grizzly, you can inject a Grizzly specific Request object.

If I choose in-memory container, can I then encounter a situation of code that passes test, but fails in production (I will use Tomcat in production, if that matters)?

Mainly if you use items mentioned above.

See an example of where a servlet environment is required. Here, there was a Servlet Filter being used for security. So the filter needed to be configured in the test. And another example where HttpServletRequest is needed

Community
  • 1
  • 1
Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
  • It is a pure luck to have such a guru online )) – Vasiliy May 04 '17 at 19:25
  • But one thing is still not very clear: can I have passing tests and failing code? I mean if I will start using these features in the future, will my tests fail (which is fine), or tests will keep passing, but the code will fail in production? I guess my question is whether I can treat a unit test which uses in-memory container as an integration test of some kind... – Vasiliy May 04 '17 at 19:27
  • I mean once you use the test framework, it pretty much is an integration test, whether you're using Grizzly or In-memory provider. It just depends on the features you're using in your code that determines whether or not you can get away with using the In-memory provider. Both provider run the application through the same Jersey engine. It's just with the "server" providers it goes through an extra server layer – Paul Samsotha May 04 '17 at 19:30
  • I still don't see the whole picture, but, I guess, it is just a matter of more hands on experience. Good thing is that switching containers seems to be easy, so I can change my mind in the future. Thanks – Vasiliy May 04 '17 at 19:35