CALL FOR: Creating a 'tests' CVS module (ends Wednesday 5 march 2003 10:30)
Called by: Michiel Meeuwissen Total tally on this call : +8
YEA (8) : Daniel Ockeloen, Kees Jongenburger, Pierre van Rooden, Rico Jansen, Wilbert Hengst, Nico Klasens, Rob van Maris, Gerard van Enk, Mark Huijser
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (7): Eduard Witteveen, Johannes Verelst, Jaco de Groot, Marcel Maatkamp, David van Zeventer, Rob Vermeulen
Call Result: New test cvs module accepted, can be created
Michiel Meeuwissen wrote:
Call for:
Creating a 'tests' CVS module and moving all tests from speeltuin and from 'src/org/mmbase/test' to it.
Description: ========================================
There is currently no 'official' way to test (parts of) the MMBase code. There is also no 'official' way for developers to implement tests for their new code.
We see however that tests appear on several places in our mmbase repository. Some of us put junit and other tests in the 'speeltuin' CVS module.
There are also 'junit' tests in the 'src/org/mmbase/test' module of our repository which were meant to test the bridge. The build.xml contains several targets to arrange the test (downloading junit, setting up a sample mmbase, running tests). Unfortunately these tests are currently broken, for some reason.
My proposal is to move all tests to one consented location namely the proposed 'tests' module.
In this module we will find a build.xml, which contains the current stuff from build.xml related to junit, plus a bunch of targets to call the several automated tests. Of course an 'all' target will be added to do all automated tests. This target could e.g. be called by the nightly build process to generate statistics about failed tests and so on.
I think there will be found subdirectories in this module related to projects or hacks. E.g. a 'dbsq' directory, and a 'typerel' directory. And below those directories you could find a reflection of the org.mmbase package structure only with -Test classes in them (I follow the suggestion of Rob van Maris in speeltuin). We could also expect an 'org' directory containing tests for base mmbase classes not specific for a project.
Other tests (non-junit) can also be put somewhere. I think that e.g. my taglib-test-jsps can be put in tests/taglib/jsp or so.
Tests for 'applications', e.g. the media application will not be stored in this tests module, but in their own. The tests modules could however provide the generic tools (build.xml targets which can be called or so), to execute those tests.
I'll appreciate some further discussion about a nice directory structure now, but I think it would be no problem to change it later on, and start experimentating now.
Because the 'junit' targets of the build.xml are broken any way I propose to remove them from the 1.6 build.xml as well.
START OF CALL: Friday 28 february 2003
END OF CALL: Wednesday 5 march 2003
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
