geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [Testing] New test directory(s)
Date Wed, 13 Aug 2003 06:45:51 GMT
I strongly suggest that we do not use generic names for modules like 
web or jms.  Doing so will make it difficult to manage large re-factors 
which are going to be likely once this project gets more mature.

For example, if we started out with a kernel module, which implemented 
a JMX based kernel, when and if we ever re-factored to use Container-X, 
the second impl would be forced to work around the namespace of the 
previous impl.


On Wednesday, August 13, 2003, at 01:32  AM, James Strachan wrote:

> Geronimo is gonna have a very modular build. There will eventually be 
> quite a few modules for the core container, jsr 77 implementation, web 
> connector, Axis connector, jms integration and so forth.
> Each module will have its own Maven build and should have its own unit 
> tests for just that module. Then developers working on one part of the 
> system can hack code, refactor in their own part of the system without 
> having to build everything else.
> For specification / functional tests, we'll probably want a full 
> container (or at least several modules) on which to do the tests. e.g. 
> EJB tests will need deployment + ejb + transactions and maybe jms for 
> example. So having the specification tests inside a module might be 
> the wrong granularity.
> So we might want a completely separate Maven project which is all of 
> the functional tests of the system. i.e. it takes a binary build of 
> the whole container & runs functionality testing on it.
> e.g. our directory structure could be...
> geronimo
> 	# root project
> 	modules/
> 		core/
> 			# core container
> 		web/
> 			# web connector
> 		axis/
> 			# axis connector
> 		jms/
> 			# jms connectors
> 		...
> 	testsuite/
> 		# the functional tests which test the whole container
> Then you can build a module (say the jms module) and run its unit 
> tests. Or you can build the whole container (building all the 
> sub-modules) and run all the tests on the entire container.
> Who knows the functional tests might become reusable as themselves - 
> on other containers or projects (heck Sun could use them in the TCK if 
> they wish) so keeping the tests in a separate build might help folks 
> reuse the functional tests elsewhere - like the jms tests the OpenJMS 
> guys did.
> On Tuesday, August 12, 2003, at 06:02  pm, Bruce Snyder wrote:
>> This one time, at band camp, Alex Blewitt said:
>> AB>At present, we only have one test directory in the source code. 
>> IMHO we
>> AB>need at least two -- one for the unit tests, and one for the
>> AB>use-cases/spec-tests.
>> AB>
>> AB>Ideally code shouldn't get into CVS unless the unit tests run 100%;
>> AB>however, (naturally) we'd expect the use-cases to start off at 0% 
>> and
>> AB>climb ever towards 100% as the lifetime of the project goes on.
>> You're preaching to the choir here ;-). I'm a big believer in this
>> stategy as well because I've used it in the past and I've seen the
>> benefit in productivity. But I'm also a big believer in the test first
>> methodology. For me, writing tests before I ever write the code saves
>> me a lot of refactoring time.
>> AB>Can someone set up the Maven project structure to have the two 
>> types of
>> AB>test? If we can't have two test directories for source code, then 
>> can
>> AB>we agree on a naming convention like org.apache.geronimo for unit
>> AB>tests, and usecase.Xxx or test.Xxx (such as
>> AB>usecase.j2ee.ejb.DeploymentUseCase) to allow the two to be 
>> separated?
>> There's already a directory structure like so:
>>     src/java
>>     src/test
>> We need to keep all the tests in their respective package structure 
>> for
>> the testing of protected and package scoped objects. I suggested 
>> earlier
>> that we add:
>>     src/spec-test
>> which is where the specification tests will live. Is this acceptable?
>> AB>Also, if use-case tests are going to be different from unit-tests, 
>> do
>> AB>we want to use/allow a different suffix other than
>> How about *
>> Bruce
>> -- 
>> perl -e 'print 
>> unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
> James
> -------

View raw message