On Friday, July 27, 2001, at 03:09 pm, Gavin Jones wrote:
Jeff Turner wrote:
But then I discovered that Avalon contains it's own Unit test framework
and I thought, "oh no - not another API to learn, what's wrong with JUnit?
:) Just what I thought at first. But then, extending AbstractTestlet and writing testXxx() methods is hardly a big learning curve.
Exactly. JUnit has a learning curve of roughly 5 minutes (exagerated for the point
:). The Testlet API has about the same learning curve, and even less for someone
who already knows JUnit.
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 better or worse than the other. I am simply saying that, the more we can use common frameworks the more people will participate.
In searching for a flexible and extensible test framework, we found that JUnit does
not suffice, for example if you needed to change what "results" you gathered, it
was impossible to do so without "hacking" junit from the bottom up (test runner,
test case, test result).... there wasnt a "pluggable" architecture where you could
change these things with ease. JUnit doesnt report well - the description of
successful test cases dont appear in the result. The authors of JUnit, themselves,
note that the framework is not really extensible due to its high pattern density.
(When I say extensible I mean the framework itself, not the testcases). I'
m still
in the progress of looking for alternative test frameworks and although testlet is
not quite there, it could be without hardly as much work as JUnit. If you look in
the guts of JUnit there are some odd things like that fact the test result actually
runs the tests (the result of the collecting parameter pattern) and other
implementation oddities that I haven't witnessed in Testlet.
I have not looking into the testing frameworks in any detail. I was happy that JUnit, having received plenty of publicity and having been supported by Ant, was a popular and acceptable choice. I too, would prefer to adopt a well designed and flexible solution.
If there are a good number of people who feel that Testlet forms the basis for a better alternative to JUnit then I'm all for the idea - I just wish there was some consolidation rather than constant diversification!
Have folk discussed things with Erich Gamma (of JUnit)? I'm aware that I had great problems trying to get at the source code back in January and I'
m aware that there doesn't appear to be a great deal of participation in the core code. Is this the problem? Is JUnit really a one-man show?
If Testlet is to become a 'new standard' then it has a long way to go beyond simply being 'the best solution', given the widespread adoption of JUnit and its association with a lot of well established names like Erich Gamma and Martin Fowler.
It may seem that I am overly concerned about this issue, but I strongly feel that tools like loggers (e.g. Log4J, LogKit), testing frameworks (e.g.
JUnit, Testlet), build tools (e.g. Ant), coding / documentation standards (e.g. JavaDoc, DocBook) , data standards (e.g. XML), source control systems (e.g. CVS, Subversion), secure communication (SSH, PGP/GPG), all represent fundamental building blocks on which the open source community is built. Whilst diversity in end products is great, common consent on the building blocks really helps a lot.
Stuart.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------- Stuart Roebuck [EMAIL PROTECTED] Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS <http://www.adolos.com/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
