I am finished with the initial migration of the build system for the
jboss/testsuite module.
All of the subprojects/* build files have been removed. All build related
configuration is done via build.xml. This does make it a little bigger, but
it is well sectioned and I don't think you will have much trouble figuring
out where stuff goes.
The old subproject files basically just did javac, the jar tasks. All
compilation related tasks for all tests is handled by the compile-* targets.
Each test has its own jars target, which builds the jar files for that test.
Some of the old subprojects had to copy & overwrite files in the output
directory to generate the proper structure for inclusion. This is a bad
idea, and I did away with it all together. I moved some stuff about in the
src/resources directory, created a few new top-level directories to seperate
things a little better.
There is still work to be done here. We are not very consistent from test
to test. This should really be cleaned up even more. I would like to
figure out a nice way to make use of the ejbjar tasks & layout resources &
metadata with respect to it (as well as the war & ear tasks).
I was finally able to get the junitreport task to work. I think it does a
better job than the previous report generator, though we might want to
customize the defaults a little bit. I was still using summary1.xsl to
generate the text log which can be emailed, but it complains about
VariableReference crap, so I turned it off for the moment.
Stylesheets now live in src/stylesheets. I copy all files with filtering
from src/* output/* (that don't compile or otherwise) as a general
principle, so if you use them, make sure you depend on compile-stylesheets
(or just compile) and reference them from ${build.stylesheets}/.
I only converted the three primary testsuite running targets. I looked into
doing the rest, but I don't understand it fully. I am hoping Scott can put
these back in where needed.
To run all the tests simple use the 'tests' target:
./build.sh tests
This depends on tests-standard, tests-client, tests-security-basic &
tests-report, which covers all of the standard tests.
Once you run this, you might want to point your web browser at
output/reports/html/index.html, so you can look at the new reports. All
of the data is stored in output/reports.
Note, that I have not even looked at the bin/* scripts. with respect to new
jar locations. If you use those, be prepared for them not to work. I
wouldn't suggest using them anyways. Instead use the 'test' target, which
is basically 'run-testsuite' for the old stuff:
./build.sh test -Dtestsuite=bank
* * *
Ok, that said I did run into some problems, which I hope that others can
help me sort out faster. Here is what I got running the testsuite:
Tests 202
Failures 31
Errors 72
SuccessRate 49.01%
Time 667.926
I would have liked to return you a new build system for this module with no
failures or errors, but that would take me way to long.
I think that about covers it, but I am probably forgetting something.
* * *
I really think that we need to have a solid testsuite for JBoss in order to
produce a high quality product. That said, I am no testing expert, but as
usual I have some oppinons.
First, I think we need to have a consistent directory structure for each
tests classes, resources and metadata files.
Each JUnit test should live inside of a class ending with Test (ex.
BeanTest). I prefer a prefix here, since it shows what the class is,
rahter than specifing a modifier for it (ex. GenericServlet vs.
ServletGeneric, the second seems to imply that it is a servlet for some
generic thingy).
Each JUnit test should extend from JBossTestcase or something, which would
be responsible for doing the dirty work of deploying as well as setting up
logging.
All test components should use Log4j for all output, so that it is obvious
to everyone which messages mean there is something wrong and which are just
informative.
Lastly, I think we might need two different test of major runs, one whihc
would cover most everything and will execute rather quickly and another
which covers everything and can take as long as it wants (within reason
that is).
>From my perspective this might be more important than adding extra features,
as it will help ensure that new features, bug fixes & configuration changes
do not break things.
* * *
Let me know if you have any questions, comments or issues (as I am sure
there will be some).
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
