done
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]>
To: "James Mitchell" <[EMAIL PROTECTED]>
Cc: "Struts Developers List" <dev@struts.apache.org>
Sent: Saturday, February 26, 2005 1:16 AM
Subject: Re: struts build change questions
On Sat, 26 Feb 2005 00:18:25 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:I agree on all points.
So, you think I should yank it up to struts/current/ ?
+1
Craig
-- 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]
