I'll do that.

There were no unit tests at all (ie. no unit/src folder), which was why the
tests could not have been built and run. I've fixed that and added a dummy test,
so that the stable suite passes ok now.

Is it really neccessary to have build-unit.xml? It normally only includes
.../nbbuild/templates/xtest-unit.xml and otherwise it's empty. Our test
compilers and executors in cfg-unit.xml call directly xtest-unit.xml.

Thanks. I'll have to improve algorithm for detecting test. I can also test
existence of files:

for unit tests:

src/unit
unit/src
build.xml
build-unit.xml

for qa-functional tests:
qa-functional/src
build.xml
build-qa-functional.xml 

I see. I would thing that the starting point should be cfg-unit.xml and
cfg-qa-functional.xml, parse them and look for testbags with 'stable' or
'validation' attributes. The config files are the real definition of what tests
are available for a module. The ant files are just our way how to run those test
and the location of the test source files can be anything as long as it's
correctly mentioned in the config files. So, what you really need to look at is
the test suites definition in the config files.

>I would thing that the starting point should be cfg-unit.xml and
>cfg-qa-functional.xml, parse them and look for testbags with 'stable' or
>'validation' attributes.

All possible tests are built now. The parsing of cfg-unit.xml is done before
test execution. We can distinguish between test for differnt configuration by
using xtest.attribs. I know currently two usacas:
1) j2ee-stable - some j2ee tests requires installation of app server
2) svn-stable - tests for subversions depends on installation of subversion