If you take pure Java SE and JUnit, you can indeed test basic business
logic elements of your REST endpoints. And I agree that this is a
good/smart/lightweight thing to do.
However, I firmly believe that the "navigation" annotations
(@Path,_at_Consumes etc.) and sub-rresource navigation in particular can be a
complex,, and critical part of the "business logic" of your REST endpoints,
and that you should not consider you system _unit_ tested until you have
tested those.
I don't think you can test those without something container-like. That's
what I use JerseyTest for.
Then, because JerseyTest also capable of "migrating" up to more substantial
containers, I'm also able to perform some additional tests up to and
including some integration-type tests.
So, my dev environment consists of regular (pure)Java SE tests, and some
JerseyTest in-memory-container tests. The the other tests are part of
build/integration.
This seems good, important, and appropriate to me,and I haven't found a
better way to achieve it than JerseyTest, but I'm open to further
enlightenment both on the approach and the tooling.
Cheers,
Simon
> ---------- Forwarded message ----------
> From: cowwoc <cowwoc_at_bbs.darktech.org>
> To: users_at_jersey.java.net
> Cc:
> Date: Wed, 10 Sep 2014 18:08:41 -0400
> Subject: [Jersey] Re: Best Library to Unit Test Jersey Restful Web
> Services?
> A few months ago I asked (but did not receive a convincing answer): Why
> bother using InMemoryTestContainer if you can't test anything related to
> servlets? I mean, why do you need a container at all? Why not dump this
> code into a standard Java SE project and run JUnit against it?
>
> Also, if this is what JerseyTest is meant for, they should have just made
> InMemoryTestContainer easier to use directly. No need to create an
> abstraction on top of a single container.
>
> Gili
>
> On 10/09/2014 4:00 AM, Mikael Ståldal wrote:
>
> If you use JerseyTest with InMemoryTestContainer, then you do not have a
> Servlet environment, so "configure anything about the mounted servlet" is
> not relevant. If you depend on Servlet specific stuff, this is not for you.
>
> Perhaps JeresyTest with something else than InMemoryTestContainer is
> less useful, but JerseyTest with InMemoryTestContainer is great for unit
> tests. Please keep it and don't listen to Gili.
>
>
> On Tue, Sep 9, 2014 at 9:53 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> The problem was that you couldn't configure almost anything about the
>> mounted servlet. You couldn't set the context path, or the listening port,
>> or register an servlet listener. It was nonsense. On top of it, Jersey 1.x
>> allowed you to at least do some of these things (the functionality was
>> removed and re-added in Jersey 2).
>>
>> It is quite possible that the latest version of Jersey 2 finally does
>> this right, but by now we've all lost our patience and moved on. Besides
>> which (as I've mentioned before) I still don't see the benefit of
>> abstracting away the container... definitely not with the heavy design I
>> see going on in JerseyTest. Users can and should just do this themselves if
>> they need to (which is going to be rare).
>>
>> Gili
>>
>>
>> On 09/09/2014 12:25 PM, Robert DiFalco wrote:
>>
>> What's the issue with JerseyTest? I use it all the time with no problems.
>> I usually use it with embedded Grizzly but I've tried pretty much every
>> embedded server. Makes testing super simple. For my system I use a single
>> static JerseyTest since I don't need a unique configuration or clean slate
>> between each test. I just use the same ResourceConfig class I use with my
>> production server.
>>
>> Super simple and I don't need to remember or standup a test server
>> before running my unit tests. For your "newClient" and "target" lines I
>> just use a short cut to the static JerseyTest fixture's #target(...) method.
>>
>> My favorite thing about it is that I can run a test with the debugger
>> and step through any hard to resolve server-side bugs. I just use the same
>>
>>
>>
>> On Tue, Sep 9, 2014 at 7:30 AM, Aris Alexis <aris.alexis.gia_at_gmail.com>
>> wrote:
>>
>>> What I do is run the main application with Tomcat.
>>>
>>> For testing I use JUnit and Jetty embedded. I start it up before the
>>> testing and shut it down later.
>>>
>>> some maybe helpful hints:
>>>
>>> Client client =
>>> ClientBuilder.newClient().register(MoxyJsonFeature.class);
>>> Response response =
>>> client.target(hostname+"/users/"+otherUserId).request().header("Cookie",
>>> getSessionId()).get();
>>>
>>> assertEquals(Response.Status.OK.getStatusCode(),
>>> response.getStatus());
>>>
>>> cheers
>>>
>>> Best Regards,
>>> Aris Giachnis
>>>
>>> On Thu, Sep 4, 2014 at 10:45 AM, Vetle Leinonen-Roeim <vetle_at_roeim.net>
>>> wrote:
>>>
>>>> On 04.09.14 04:09, Andre Perez wrote:
>>>>
>>>>> I am using JDK 1.7, Jersey 2.12, Tomcat 7, MongoDB and RestAssured
>>>>> <https://code.google.com/p/rest-assured/> to unit test my Rest
>>>>> calls...
>>>>> The issue is that RestAssured needs Tomcat to be running with my war
>>>>> file,
>>>>> in order, to work. Is there an embedded server or in-memory server
>>>>> along
>>>>> with a different unit testing framework which I can use to test my
>>>>> Restful
>>>>> Web Services (basically without be tightly coupled to an external
>>>>> server)?
>>>>> Would love to hear people's suggestions regarding best practices?
>>>>>
>>>>
>>>> We have great experience using JerseyTest (
>>>> https://jersey.java.net/documentation/latest/test-framework.html). The
>>>> in-memory test container works great, and enables us to run tests in
>>>> paralell, and we replace beans in some tests when we need to.
>>>>
>>>> Our tests usually start a in-memory container with JerseyTest, and then
>>>> just do `jerseyTest.target(someUri).request() ...` to access the server and
>>>> perform our testing.
>>>>
>>>> If you need Tomcat, you can still use JerseyTest and just configure it
>>>> to use an external container (
>>>> https://jersey.java.net/documentation/latest/test-framework.html#d0e15742),
>>>> but I suppose you will lose some of the advantages - you most likely have
>>>> to create something to actually start Tomcat and deploy your WAR file.
>>>>
>>>> Good luck!
>>>>
>>>> Regards,
>>>> Vetle
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Mikael Ståldal
> Chief Software Architect
> *Appear*
> Phone: +46 8 545 91 572
> Email: mikael.staldal_at_appearnetworks.com
>
>
--
Simon Roberts