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
> <mailto: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 <mailto: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 <mailto: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
> <mailto:mikael.staldal_at_appearnetworks.com>