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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
