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