On Dec 1, 2009, at 4:37 PM, Guillaume Berche wrote:
> Hi Paul,
>
> You're right, the tests I was trying to write are probably
> overlapping with jersey framework own tests of parameter passing to
> resources.
To some extent, but that was not really what i was getting at. I think
i understand better now that you have presented some use cases.
> So just placing a single simple assertions in manually crafted mock
> resource implementation is probably sufficient in most cases. For
> the sake of detailing my original intentions I tried to provide
> sample use-cases below.
>
OK, i better see what you are getting at now. Hmm... the first thought
that comes to mind is i would probably write specific tests with
services that return back information to the client rather than reuse
existing resource interfaces.
E.g. a test for the @QueryParam("view") could be:
@GET
public String testView(@QueryParam("view") @DefaultValue("full")
QuestionResource.View view) {
return view.toString();
}
i.e. reuse HTTP as the mechanism to report information that can be be
tested on the client side.
Paul.
> Thanks for your help,
>
> Guillaume.
>
> ---------------
> Here is a first example of what I was trying to test: Say I have the
> following Resource
>
> public interface QuestionResource {
>
> @GET
> public QuestionDTO getQuestionById(@QueryParam("view")
> @DefaultValue("full") QuestionResource.View view);
>
> }
>
> I would like to write test cases like
>
> case 1:
> questionResource.queryParam("view",
> QuestionResource.View.full.name()).get()
>
> //assert that the "QuestionResource.View.full" enum instance was
> received as parameter view
>
> case 2:
> questionResource.queryParam("full",
> QuestionResource.View.full.name()).get()
> //assert that the "QuestionResource.View.small" enum instance was
> received as parameter view
>
>
>
> A second example could the testing MessageBodyWriter<T> classes
> provided by the application. In the jersey sample entity-provider
> example, as a developer I would like to test passing different
> parameters to the MapResource.updateDataItem(NameValuePair item) and
> assert that they were received properly (e.g. form data with mutiple
> multiple parameters with same name, or some parameters without
> value...). If I locate my assertions into a manually crafted
> MockMapResource.updateDataItem(NameValuePair item) method, then I
> need to create as many resource mock classes as I have assertions.
>
> > Hi Guillaume,
> >
> > This is the first time i have heard of such a use-case.
> >
> > I am not sure i fully understand why you need to separate out the
> > assertion checking from the parameter receiving. Why can't you make
> > the assertions directly in the mock resource implementation, since
> is
> > that not the best place to make such assertions?
> >
> > Paul.