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.