On 03/19/2014 07:09 PM, cowwoc wrote:
> On 19/03/2014 3:30 AM, Vetle Leinonen-Roeim wrote:
>>> My advice to you: dump JerseyTest. Its design is flawed and it doesn't
>>> look like it'll get fixed anytime soon. You can replace Jetty with your
>>> server of choice. Just dump the abstraction (JerseyTest) and talk
>>> directly to the server.
>>
>> Have you tried Jersey 2? As long as you don't need the servlet API,
>> you can use an in-memory container when running JerseyTest, and blast
>> away. It's really neat.
>
> I don't plan to upgrade to Jersey 2 until the critical features missing
> from Jersey 1 are fully ported over. The major one that comes to mind is
> ResourceContext: http://stackoverflow.com/q/17284419/14731.
>
> As for running an in-memory container:
> http://stackoverflow.com/q/13283542/14731
>
> Meaning, I don't understand (and I genuinely want someone to explain to
> me) what an in-memory container gives you that a normal JUnit test
> (without a server) does not.
For me it helps with the integration tests. I can easily deploy the
whole application, run integration tests in parallel if I want to, on a
shared build server.
I suppose using JerseyTest you can make sure your writers and readers
are functioning properly. For instance, you can of course write a unit
test for a writer, but if you use JerseyTest you can add a resource that
expects the reader or writer to work properly with whatever it consumes
or produces. So in this way it enables you to test that setup is correct.
> So to answer your question, all my unit tests assume the existence of
> the Servlet API so the above is the best I can do.
Yeah, it seems that the preferred route in Jersey 2 is to not depend on
the servlet API at all. If that can be accomplished, then I really like
the flexibility Jersey 2 provides wrt using the different containers
(not just for tests).
When it comes to integration tests - again - if you're not depending on
the servlet API. then it's just a matter of setting it up with your
ResourceConfig, and target("whatever").request() ... and so on. Simple!
Regards,
Vetle