[
https://issues.apache.org/jira/browse/SHINDIG-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603343#action_12603343
]
Brian Eaton commented on SHINDIG-364:
-------------------------------------
> Hmm -- maybe the problem *is* the interface? Instead of HttpFetcher.fetch,
> perhaps we should have HttpFetcher.get, HttpFetcher.post, HttpFetcher.head,
> etc.?
Interesting idea. It would get really annoying if we ever wanted Shindig to
support WebDAV or the like, but we'll probably stick to the core HTTP/1.1
methods.
Of course, everyone who implemented HttpFetcher.put would need to turn around
and write their own test cases for it. Having a set of reusable tests would
still be handy, even if the interface did a better job of describing the
contract.
> Don't move BasicHttpFetcherTest -- make it *use* the new HttpFetcherTestCase
> (or whatever it's called). Tests of Shindig's core need to remain in src/test
That's what I've done. Unfortunately I needed to move BasicHttpFetcherTest out
of the java/gadgets/src/test and into java/testing/src/test, to avoid circular
dependencies between java/gadgets and java/testing.
So we hava java/testing/src/main, which has the reusable stuff, and
java/testing/src/test, which has the Shindig core testing. I'm not thrilled
with that, but I can't think of a better idea right now.
> 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.
