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]
