I agree on all points.
So, you think I should yank it up to struts/current/ ?
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Friday, February 25, 2005 11:56 PM
Subject: Re: struts build change questions
On Fri, 25 Feb 2005 23:40:41 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:<snip/>
> It seems to me that a framework which ships (and supports) a > ready-made set of mock classes will have an advantage in today's > world.
Yes. It's interesting how things work out. Over the years I used to swear
by in-container based test suites, but after fighting with Cactus and
fiddling with a few others I have a new appreciation for Mock vs.
in-container testing.
Aren't there already Mock test frameworks out there that we can use? I mean, why reinvent the wheel? I could see a problem if the license were incompatible. Your thoughts?
From what I have seen (not exhaustive review, but high level observation):
* There are indeed a large number of MockXXX libraries in the world.
* So many of them, in fact, that it's hard to decide what combination you need
to cover all the base classes you need.
* Because there is no standardization of what a mock should do, there is a wide variety of extra API in the various versions.
* The available mock libraries tend not to be a product of the frameworks they contain mock implementations for, meaning: - Not necessarily synchronized with the latest changes in the framework - Not necessarily suitable for testing intra-framework classes (i.e. more focused on user apps) - Not necessarily at the same quality level as the framework under test.
* No matter what the quality, the need to go someplace else (or several someplaces else) to gather suitable test frameworks is a burden on the user of the framework.
Contrast that with a world where:
* Each release of a framework has a corresponding release of a mock objects framework that has been synchronized with the latest changes in the functionality.
* The test framework is used by both the developers of the framework, and the developers of apps based on the framework, which will tend to reduce the inevitable behavior differences between the mocks and the "real thing".
* No shopping around the Internet for multiple pieces of code that you need to integrate, or evaluate licenses for, or badger to update when something changes in the underlying framework.
It's not an issue of where you get the original code from (I wrote basically all of the code in Shale's test framework, so I am willing to vouche for it and support it; if we can find a suitable starting point somewhere for Struts that is willing to contribute code, great!). It's the fact that the mock objects are supported by the same folks that are supporting the framework is a very important value add.
Note that, because I'm a fan of mock objects, this particular solution is focused around JUnit-based unit tests. That's not the only possible answer to what kinds of testing gadgets you need (Cactus, for example, makes it easy to build a different sort of test); but it's certainly the foundation level. I believe something like this should become a standard deliverable of a framework (whether it is actually developed by the same developers, or only in close cooperation with them, is less important).
<snip/>
> FWIW, in retrospect, I see that I chose "core-library" in both faces > and shale. Might be worth considering.
You mean name the jar produced by struts/current/core/ as "core-library-x.y.z.jar" ? That seems a bit ambiguous doesn't it? I mean, core library for what? Wouldn't that be confusing having a naming clash with Shale?
It might indeed ... shale-core.jar would likely make more sense if Shale ends up being the final name. But that doesn't necesarily dictate that the source repository needs to have the same name (where there is no opportunity for confusion).
After all, people persist in the habit of adding version numbers to jar file names (a habit I detest, but that's a whole different story), so the directory name doesn't match the JAR file name anyway, in many cases.
Craig
<snip/>
> Craig
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
