While I was looking at Brian's modifications on the build.xml, I thought
that the mechanism we currently use for specifying the list of tests to
include in the CC buildloop, is rather clumsy.
I thought that too, but took the attitude "if it aint broke, dont fix it"
Currently the SlickRunner bundle would read the
net.java.sip.communicator.slick.runner.TEST_LIST property and extract a
whitespace separated list of test names out of it. Each of these names
is a service.pid so the SlickRunner would run a search for OSGI services
corresponding to each of these names and execute them one by one.
I had to fight the temptation to research the mechanism. I could see it
wasn't straightforward, but felt tinkering with it was outside the scope
of my own task.
The nasty thing about all that is the fact that the list of tests to run
is growing bigger and bigger so the build.xml is obviously not its place
(not to mention the fact that it is virtually impossible to run that
from the command line).
I agree. build.xml should be highly stable because it tends to be very
complex in any serious project. If someone breaks a build, everyone
shares the pain.
So I belieave that it would be a good idea to have this list in a
separate file and replace the
net.java.sip.communicator.slick.runner.TEST_LIST property with
(And if possibly without breaking support for TEST_LIST)
Some of my own projects still rely on a explicit lists of test classes. They
are stable, so I don't worry too much about the risks. However, I can still
remember situations where I wasted a lot of time because I'd forgotten
to add a new test class to the list.
netbeans has 2 (well, four really) kinds of projects... those like ours are
called "with existing ant script", while the others have their build.xml created
by a netbeans wizard. I'm fairly hazy about the mechanism, but a netbeans
project has an <ide-action> that runs all unit tests... this is "wired" to a
build.xml target that uses introspection to create the list of unit test classes
"on the fly".
I don't know how hard it would be to do this kind of thing for slick.runner, but
a little extra effort now would save a lot of effort in the long run.
a) I assume all our unit tests will be found in the "test" project folder.
b) does each test class have a superclass (or implement an interface)
that uniquely identifies it as a class to be included in the "all tests" set?
(e.g. jUnit test classes always inherit from junit.framework.TestCase).
c) does each test method have an attribute that uniquely identifies it as a
member of the "all test methods" set within a test class? (e.g. jUnit test
methods for automatic execution have the signature...
public void testnnnnnnn ( ), where nnnnnn is an arbitray string).
d) does each test class have the equivalent of the junit setup() and
teardown() methods, or not need such things?
If the answers to these 4 questions are mostly affirmative, then there is
a strong case to create a TestRunner that class that uses introspection
to run all our tests. Isn't there one in the Oscar toolkit already? If not,
the simplest jUnit TestRunner ought to be a useful starting point as a
p.s. I just took a quick look at the service.protocol package.... each
test is in a different package, but I don't think that would be a problem.
Each test class extends junit.framework.TestCase already!!! I still
haven't "joined up all the dots" in my mind, but surely jUnit already
has an answer for our problem?
Do we need to clone the junit.textui.TestRunner class to make a
new junit.textui.OscarTestRunner? Is that it?
On Tue, 06 Dec 2005 04:42:32 +0100, Emil Ivov wrote:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com