Unfortunately I seem to end up needing information which is not available
in a pure JAX-RS application.
On Thursday, 11 September 2014, Mikael Ståldal <
mikael.staldal_at_appearnetworks.com> wrote:
> The point of InMemoryTestContainer is to cover your JAX-RS bindings with
> your tests.
>
> It is possible to build an JAX-RS application which does not directly
> depend on the Servlet API.
>
> On Thu, Sep 11, 2014 at 12:08 AM, cowwoc <cowwoc_at_bbs.darktech.org
> <javascript:_e(%7B%7D,'cvml','cowwoc_at_bbs.darktech.org');>> wrote:
>
>> 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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','mikael.staldal_at_appearnetworks.com');>
>>
>>
>>
>
>
> --
> Mikael Ståldal
> Chief Software Architect
> *Appear*
> Phone: +46 8 545 91 572
> Email: mikael.staldal_at_appearnetworks.com
> <javascript:_e(%7B%7D,'cvml','mikael.staldal_at_appearnetworks.com');>
>