You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Brian Eaton (JIRA)" <ji...@apache.org> on 2008/06/07 23:39:45 UTC
[jira] Created: (SHINDIG-364) provide reusable tests for injected
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
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.
[jira] Updated: (SHINDIG-364) provide reusable tests for injected
dependencies
Posted by "Brian Eaton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Eaton updated SHINDIG-364:
--------------------------------
Attachment: testing-package.patch
Work done in this patch:
1) Create a shindig-testing artifact that can be published for inclusion in other projects. None of the other shindig artifacts should depend on shindig-testing.
2) Move generic HttpFetcher tests into the shindig-testing 'main' code.
3) Move BasicHttpFetcher test case into the shindig-testing 'test' code.
This looks like it might work for allowing reuse of the test cases, but is slightly weird. Why do we have BasicHttpFetcherTest.java in a completely different location than BasicHttpFetcher?
> 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.
[jira] Commented: (SHINDIG-364) provide reusable tests for injected
dependencies
Posted by "Brian Eaton (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-364) provide reusable tests for injected
dependencies
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603336#action_12603336 ]
Kevin Brown commented on SHINDIG-364:
-------------------------------------
Oh, and the reason for tests being in src/test instead of src/main is because tests aren't included in artifacts (artifacts are intended for distribution, tests are not).
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
> 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.
[jira] Commented: (SHINDIG-364) provide reusable tests for injected
dependencies
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603334#action_12603334 ]
Kevin Brown 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.?
> 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.
[jira] Commented: (SHINDIG-364) provide reusable tests for injected
dependencies
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ 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.