On Oct 27, 2008, at 3:39 PM, Gili 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.
>
Good point. I hope there is more degree of isolation than WS-* since
there is no dependency on description languages (WSDL and XSD, which
are two major sources of interop pain) and for the client you do not
have to use JAXB to produce or consume XML that was produced/consumed
using JAXB on the server side.
Paul.
> 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
>