[
https://issues.apache.org/jira/browse/SHINDIG-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603349#action_12603349
]
Kevin Brown commented on SHINDIG-364:
-------------------------------------
With your current patch, running tests on java/gadgets will no longer run any
http tests at all. AllTests passes even if I introduce bugs in
BasicHttpFetcher. That's not right, and much worse than someone potentially
implementing a custom HttpFetcher and not correctly implementing according to
the spec.
The vast majority of users will not be using their own HttpFetcher (even fewer
than today once we get it moved to the commons http client), which would mean
that we're optimizing for the minority who don't bother read the specification
(much less the javadoc) at the expense of the overall quality of the standard
implementation.
Similar problems exist with every other interface that users are expected to
implement (the primary interfaces in social-api, as well as GadgetSpecFetcher,
MessageBundleFetcher, etc.). At some point we have to assume that people using
our code are competent; the incompetent ones would ignore the tests anyway.
A simple end-to-end selenium test for gadgets.io.makeRequest would probably
solve the problem without having to have weird dependencies .
> provide reusable tests for injected dependencies
> ------------------------------------------------
>
> Key: SHINDIG-364
> URL: https://issues.apache.org/jira/browse/SHINDIG-364
> Project: Shindig
> Issue Type: Bug
> Components: Gadget Rendering Server (Java)
> Reporter: Brian Eaton
> Attachments: testing-package.patch
>
>
> Problem: dependencies injected in to Shindig are expected to fulfill
> contracts that are not completely specified by their interfaces. For
> example, HttpFetcher implementations need to support GET, PUT, POST, and
> DELETE methods, and also need to return the body of HTTP error responses.
> It's easy to write test cases for this for any particular HttpFetcher
> implementation (we have them for BasicHttpFetcher), but it is slightly
> trickier to reuse those test cases against other HttpFetcher implementations.
> Quite a bit of this trickiness is introduced by maven, unfortunately.
> I'm attaching a patch that takes a first swing at artifact creation and
> renaming to allow the BasicHttpFetcherTest test cases to be reused for
> arbitrary HTTP fetchers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
