Hi Andy,
I've been doing the same (using Mockito). The only bit I am questioning is
applicationsResource.setUriInfo(). I am reluctant to expose any
test-specific functions in the applicationsResource. In an ideal world
UriInfo would be passed in the constructor along with the other objects
being injected. Unfortunately Guice knows how to inject one half of the
objects, Jersey the other, and I don't think they can (currently)
interoperate on this.
For now I am looking into getting Guice to inject UriInfo as null in
production (both into the constructor) and as a mock during testing. At
least then I'm not exposing any testing-specific methods and when
Guice/Jersey learn to interoperate in the future this will work in the same
fashion except that then UriInfo won't be null for production.
Gili
Andrew Ochsner wrote:
>
> FWIW, we've been mocking out the UriInfo object.
>
> Have a look at Mockito, JMock, or EasyMock. Since you're new to mocking
> you
> might want to understand what mocking is and how it's different from
> stubbing etc.
>
> Here's an example (using Mockito):
> The Resource calls UriInfo as such:
> URI bookmarkUri =
> uriInfo.getAbsolutePathBuilder().path(createdApplication.getId()).build();
>
> import static org.mockito.Matchers.isA;
> import static org.mockito.Mockito.mock;
> import static org.mockito.Mockito.stub;
>
> UriInfo uriInfo = mock(UriInfo.class);
> uriBuilder = mock(UriBuilder.class);
> stub(uriInfo.getAbsolutePathBuilder()).toReturn(uriBuilder);
> stub(uriBuilder.path(APP_ID)).toReturn(uriBuilder);
> stub(uriBuilder.build()).toReturn(new URI(URI));
> applicationsResource.setUriInfo(uriInfo);
>
> HTH
> Andy O
>
> On Mon, Oct 27, 2008 at 8:39 AM, Gili <cowwoc_at_bbs.darktech.org> wrote:
>
>>
>>
>> I was originally considering doing this but I don't like the idea of
>> using
>> too many components from the same vendor. You risk running into the same
>> bugs that WS-* developers used to runs into: everything works fine when
>> the
>> entire technology stack comes from one vendor, but breaks in subtle ways
>> when you use another.
>>
>> By writing the tests from the ground up I am hoping to reduce that risk.
>> By
>> ripping out the network layer I am verifying that my resource code is
>> correct independent of any JAX-RS implementation. Later integration tests
>> that run against the full network and database stack should catch those
>> other issues.
>>
>> Gili
>>
>>
>> Paul Sandoz wrote:
>> >
>> > Hi Gili,
>> >
>> > I am not convinced that mocking-up without using HTTP is the correct
>> > approach, you application is designed to be consumed by HTTP clients,
>> > IMHO should be tested using a similar mechanism, with code coverage
>> > analysis telling you what bits of the server side are not currently
>> > tested. But others views differ.
>> >
>> > The Jersey tests do the following:
>> >
>> > - use embedded HTTP servers like Grizzly, GF and Jetty; or
>> >
>> > - use a special in memory connection.
>> >
>> > and make use of Jersey client API. The tests are not really unit tests
>> > more functional tests that use the unit test framework because it is
>> > so convenient. We are planning to create a separate testing framework
>> > to make it easier for developers to create such tests.
>> >
>> > Paul.
>> >
>> > On Oct 26, 2008, at 7:44 AM, Gili wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> I'm trying to unit test resources containing the following field:
>> >>
>> >> @Context
>> >> private UriInfo uri;
>> >>
>> >> The problem is that @Context is never injected under the unit test
>> >> (because
>> >> there is no servlet layer) so uri ends up being null. All my tests
>> >> end up
>> >> failing with NullPointerExceptions as a result.
>> >>
>> >> I'm wondering what one is supposed to do in such a case. I read one
>> >> could
>> >> mock-up such objects but I've never done this sort of thing before.
>> >> I'm also
>> >> not sure when/how to inject the mocked-up UriInfo into the class. I
>> >> don't
>> >> think I can add it to the constructor because I don't want to impact
>> >> how
>> >> this class runs in production mode. I guess I could add setUriInfo()
>> >> and
>> >> call it only from my unit tests but that seems a bit fragile.
>> >>
>> >> Please advise.
>> >>
>> >> Thanks,
>> >> Gili
>> >> --
>> >> View this message in context:
>> >> http://n2.nabble.com/Unit-tests-and-UriInfo-tp1378335p1378335.html
>> >> Sent from the Jersey mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Unit-tests-and-UriInfo-tp1378335p1382621.html
>> Sent from the Jersey mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Unit-tests-and-UriInfo-tp1378335p1382698.html
Sent from the Jersey mailing list archive at Nabble.com.