Stuart Roebuck wrote:
>
> I'm sure your right that the learning curve is quick, but nobody wants to
> bother starting to learn something they don't have to, so, if an open
> source project uses a whole set of unique utility APIs it is less likely
> to receive participation from people on the periphery who haven't the time
> to see whether learning something is going to be a quick or a slow process.
>
> In other words, I'm not arguing that either API is quick or slow to learn,
> nor that either framework is bette
For the simple things we are doing, it is easy to convert between them--so
I have an idea to abstract some of the logic and use your prefered tool with
the same logic. I personally don't care one way or the other--but I do care
about this much:
JUnit has a nice graphical UI--it's mostly eye-candy but sometimes the
visual feedback is better than scrolling through a long list of log
entries.
Also--this is not addressed by either framework--but is an EXCELLENT feature
(it exists in a commercial $4000 product):
Automatic discovery and excersizing of all public and protected methods.
This is a long and expensive test--but it is how we found out that the
some of the components were not storing correct object types.
No matter what testing framework we use, it needs to be robust, and we
need a series of standard tests to run on all Components. For configurable
objects, we need to have a schema so that we can test both valid and invalid
configurations.
The more the tool can do for us, the better the tool. The less we have to
*do* the more useful it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
