avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: [Testlet] Why another unit test framework?
Date Fri, 27 Jul 2001 15:47:48 GMT

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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message