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]
