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. 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.
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.