[ http://issues.apache.org/struts/browse/SHALE-210?page=comments#action_37655 ]
Craig McClanahan commented on SHALE-210: ---------------------------------------- Several thoughts and notes: * If we decide to keep this, I'd prefer that it ends up in a separate package (org.apache.shale.test.jmock) because the dependency should be optional. * In a similar vein, the POM updates should mark these dependencies as optional so nobody who isn't using JMock is affected. * As presented, this base class duplicates a bunch of the setup/teardown code in AbstractJsfTestCase, which means we'll need to do double work if any future changes to that class occur. Is there any way we can satisfy the JMock requirements by writing a class that extends AbstractJsfTestCase and then implements some JMock-specific interface instead? * In particular, the only unique thing being done seems to be setting up a thread context class loader. IMHO, that would be a good addition to AbstractJsfTestCase directly -- and that it would be great if that made the same base class suitable for JMock use as well. If not, we should look further at how to avoid having to duplicate code (see previous point). > Adding JMock environment for convenience > ---------------------------------------- > > Key: SHALE-210 > URL: http://issues.apache.org/struts/browse/SHALE-210 > Project: Shale > Type: New Feature > Components: Test > Versions: 1.0.3 > Reporter: Matthias Wessendorf > Attachments: jmock_base_clazz.patch, jmock_base_clazz.patch, > jmock_shale_test.patch, jmock_shale_test.patch > > Having a clazz like AbstractJMockJsfTestCase is a nice convenience for people > are interested in using JMock. > for some reasons this approach is needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
