commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zeigermann, Oliver" <ozeigerm...@c1-fse.de>
Subject RE: [testutils] Is there any commons area for generic test code?
Date Fri, 11 Jun 2004 12:51:22 GMT
I have created a concurrent package under o.a.c.test. I guess "Threading" and "Futures" might
fit there perfectly...

Oliver



-----Original Message-----
From: Arnd Kohrs [mailto:ak.lists@free.fr]
Sent: Fri 6/11/2004 2:15 PM
To: Jakarta Commons Developers List
Subject: Re: [testutils] Is there any commons area for generic test code?
 
Alex Karasulu wrote:

 >
 > Back on topic, I'm fine with guidelines. But I only have general ones at
 > the moment:
 >
 >  o I want to minimize dependencies avoiding them whenever possible.
 >  o Keep things simple.
 >  o This should not be an area for dumping project test code.
 >  o Keep the amount of specificity low: meaning this is not where you
 >    keep your test cases for testing an LDAP server or a cryptography
 >    library etcetera.  It should be for generic test utilities
 >    in addition to junit used for writing unit tests, beta tests,
 >    and stress tests
 >  o Commons-test should be here for making your domain specific
 >    TestCases all that much easier to write while avoiding the
 >    duplication of common testing and setup code.
 >
 > Alex
 >

Hi Everyone,

contrary to as someone pointed out on this thread I think this subject 
is very exciting.  For my development projects I have also founded a 
package of extensions for JUnit testing:  The following areas were 
important so far:
  - Assertions for common issues: instanceof, thrown exceptions, array 
element equality etc.
  - Threading: validate error free execution and termination of threads.
  - Futures: constraints Future objects.
  - Beans: validate property accessors and property change events.
  - DataObject: validate implementation of equals, hashCode and 
serialization.
  - Logging: add log interface to TestCase
  - Watchdog: terminate test after maximum execution time.

Some extensions are static and others integrate with the JUnit 
framework, ie. inherit from TestCase in order to maximize automation.

The intention of the extensions was to permit to write JUnit test-cases 
quickly without duplication and simple access to the features also for 
the not-so-seasoned JUnit users.  So these extensions are all accessible 
through one TestCase class: BellsAndWhistlesTestCase.

This is all to say that I encourage the effort to found the sandbox 
project.  I will try to contribute from these if suitable once the test 
project materializes.

For these extensions dependencies on Logging, BeanUtils and even 
Functors have been introduced.
I do not see the need to avoid dependency in a test-utils project. 
Test-utils are used during the development and are usually not part of 
the developed product.  I would not put the minimization of dependencies 
too high on the agenda, as the testing has a different scope.

For the name, IMO 'testutils' is a better choice than 'test' as it 
provides for less ambiguity.  Maybe even the focus on UnitTesting should 
be highlighted: 'unittestutils'.

Cheers,
Arnd




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






Mime
View raw message