On Mar 10, 2010, at 5:09 PM, Florian Hehlen wrote:
> Hi,
>
> Using Grizzly would be my first choice, but I am crippled by an
> environment where any testing dependencies will also end up in my
> production!
>
> The other thing is that we are not using Hudson but good old fashion
> ant!
>
I think ant is an orthogonal issue. You can use ant with Hudson too
and there are some very handy ant-based maven utilities if you need to
integrate with a maven repo.
> If I was using Grizzly would I be able to do tests like I suggested
> below?
No.
> I think it is key to test that the URL binding is binding to the
> right methods. I have APIs with many many finder-methods that all
> return lists of a same entities. The key thing would be to have a
> single instance of a resource that I can access both by making
> direct method calls and restful calls.
>
> Another key thing is that I would like to avoid having to use Spring
> in my unit tests. I would like to instantiate a Resource class, set
> it’s dependencies by hand, and then wrap it in a jax-rs container….
> Am I asking for to much?
>
Perhaps :-) I have seen other developers mock up resources, but i am
not experienced in this mock up approach to help you, sorry :-(
One way you can make this easier is to always use constructor
injection in your resource classes. Then it becomes much easier to
pass in mocked objects to the constructor.
To be honest i do not see much advantage to mocking up stuff as to
actually using the stuff with an embedded or in memory container. To
steal a phrase from Rich Hickey (Clojure inventor) "Those mock
objects, they are mocking you". The mocking seems to require a bunch
of extra code where as if one configures things to say use an in-
memory or embedded container in conjunction with the client API then
you are testing the artifacts far more closely to as they are intended
to be used.
Paul.