Re: class hierarchy and extending a Cactus Test Case
Hi, In article [EMAIL PROTECTED], Wed, 18 Jul 2007 16:16:56 -0500, Jay Baker [EMAIL PROTECTED] wrote: jbaker.work Thank you for your interest. Let's say that I have a base class that is used jbaker.work for regular (not in container) test cases. Call this MyBaseTestCase. I have jbaker.work other test classes that extend this base class. The base class provides jbaker.work services that I need and the current design uses inheritance. For example, jbaker.work it uses a template pattern approach to enforce that some metadata is jbaker.work available. So we have: Thank you. I could understand better. Many of testing-frameworks use the template pattern and have their own base-class (not an interface) to be inherited. As Java doesn't support multiple inheritance, I think it is better to have separated utility class which provides services currently provided by your MyBaseTestCase class so that you can utilize such service independently of object hierarchy of its client. By doing so, you could avoid similar issue when you will try other frameworks, eg. StrutsTestCase. In article [EMAIL PROTECTED], Tue, 17 Jul 2007 11:11:25 -0500, Jay Baker [EMAIL PROTECTED] wrote: jbaker.work It seems that I have four choices. [snip] jbaker.work 4. Change the design of existing code base that I have so this is not an jbaker.work issue. I can't really afford to do this at this time due to the effort and jbaker.work risk involved. If I were you, I would take this approach. To minimize the risk you are worrying about, you would change only codes that relate to Cactus for this time. # I suggest step-by-step refactoring. Best Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: class hierarchy and extending a Cactus Test Case
Hi, In article [EMAIL PROTECTED], Tue, 17 Jul 2007 11:11:25 -0500, Jay Baker [EMAIL PROTECTED] wrote: jbaker.work I am using ServletTestCase. Extending this test case works just fine. No jbaker.work problem. However, I have an existing object hierarchy that I would like to jbaker.work preserve. Although all of the Cactus documentation discusses extending one jbaker.work of the Cactus tests, I figured I could just implement some appropriate jbaker.work interface(s) and use delegation. As I read further, I understood the use of jbaker.work publicly accessible attributes of the various Cactus test cases. If this jbaker.work access were done through getters and setters, I would have no problem. I cannot understand what you want to do, so am having questions. Q1: What is the object for which you want to preserve its object hierarchy? Q2: What is the relation of the object and Cactus? Q3: How should the object and Cactus work together? A safe example would be helpful. Best Regards, Kazuhito SUGURI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: class hierarchy and extending a Cactus Test Case
Thank you for your interest. Let's say that I have a base class that is used
for regular (not in container) test cases. Call this MyBaseTestCase. I have
other test classes that extend this base class. The base class provides
services that I need and the current design uses inheritance. For example,
it uses a template pattern approach to enforce that some metadata is
available. So we have:
public class TestCase03 extends MyBaseTestCase {
... }
Now I want to add in container testing using Cactus. I could do:
public class TestCase04 extends ServletTestCase {
... }
but I don't want to because of the existing hierarchy I have.
So I tried:
public class TestCase04 extends MyBaseTestCase implements CactusTestCase {
...}
and delegated to an instance of ServletTestCase for the implementation of
the CactusTestCase interface. That did not work however. To check things
out, I created my own class MyCactusBaseTestCase that looks very much like
ServletTestCase but it extends MyBaseTestCase. This works, but I would
prefer to not rely on the source code of ServletTestCase.
I hope that clarifies things a bit and thanks for your help.
-- Jay
On 7/18/07, Kazuhito SUGURI [EMAIL PROTECTED] wrote:
Hi,
In article [EMAIL PROTECTED],
Tue, 17 Jul 2007 11:11:25 -0500,
Jay Baker [EMAIL PROTECTED] wrote:
jbaker.work I am using ServletTestCase. Extending this test case works
just fine. No
jbaker.work problem. However, I have an existing object hierarchy that I
would like to
jbaker.work preserve. Although all of the Cactus documentation discusses
extending one
jbaker.work of the Cactus tests, I figured I could just implement some
appropriate
jbaker.work interface(s) and use delegation. As I read further, I
understood the use of
jbaker.work publicly accessible attributes of the various Cactus test
cases. If this
jbaker.work access were done through getters and setters, I would have no
problem.
I cannot understand what you want to do, so am having questions.
Q1: What is the object for which you want to preserve its object
hierarchy?
Q2: What is the relation of the object and Cactus?
Q3: How should the object and Cactus work together?
A safe example would be helpful.
Best Regards,
Kazuhito SUGURI
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
class hierarchy and extending a Cactus Test Case
I searched the archives but, surprisingly, I could not find anything on this. I am using ServletTestCase. Extending this test case works just fine. No problem. However, I have an existing object hierarchy that I would like to preserve. Although all of the Cactus documentation discusses extending one of the Cactus tests, I figured I could just implement some appropriate interface(s) and use delegation. As I read further, I understood the use of publicly accessible attributes of the various Cactus test cases. If this access were done through getters and setters, I would have no problem. It seems that I have four choices. 1. Implement some arcane introspective state listener such that I can transfer state changes in my base class to a delegate Cactus class. I'm not even sure how to do that off the top of my head and I don't like the idea very much. 2. Copy implementation from an appropriate Cactus class to my base class. I also don't like this. It is poor design and couples my base class too closely to this version of Cactus. Of course, it would work. 3. Discuss contributing to Cactus such that the framework will permit a design that could use delegation. This would be fine, but it can not meet the time frame requirements that I have. 4. Change the design of existing code base that I have so this is not an issue. I can't really afford to do this at this time due to the effort and risk involved. Any suggestions from others that have been down this road before? -- Jay
