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.
On Nov 30, 2009, at 6:26 PM, Guillaume Berche wrote:
> Hello,
>
> I’d like to unit test the resources I’m developing (precisely
> validate my JAX-RS annotations as I develop them), and in particular
> make assertions on the received method parameters (such that default
> value for an Enum type are properly received as a parameter).
>
> The jersey test framework is great in the sense that it allows me to
> perform full round-trip tests with real HTTP client and server. So,
> I am testing mocked implementation of a Resource interface (that is
> my externally exposed webservice API), this implementation returns
> static data. However, I’d like to have my JUnit test class actually
> making assertions on the arguments received into this mock resource.
>
> Ideally, I’d like to be able to define my mock resource
> implementation as a singleton, and be able to somehow from by junit
> test driver get a reference to this server-side resource
> implementation, to inspect recorded received parameters and make
> assertions on them after the resource finished execution, or
> potentially inject listener classes to it. Could the
> InMemoryTestContainerFactory be used in such a way?
>
> Alternatively, I could have programmed assertions be injected into
> the resource and have them be evaluated during request execution,
> and fail assertions by returning and error response with the junit
> failure details in the response. I guess this could be done by
> injecting a class name of programmed assertion (e.g.
> org.foo.ArgumentCheckerCase1 implementing an interface such as
> ArgumentChecker) into the ApplicationDescription’s webapp init
> params so that it ends up into the @Context exposed to the Resource,
> and the resource can instanciates it through Class.forName(). In
> this case, each distinct assertion would require a container stop/
> start to pick up a new assertion class to be injected into the mock
> resource.
>
> Any other ideas or experience with similar needs?
>
> Thanks in advance for your help on this,
>
> Guillaume.