----- Original Message -----
From: "Glen Daniels" <[EMAIL PROTECTED]>
To: "Axis-Dev (E-mail)" <[EMAIL PROTECTED]>
Sent: Sunday, December 01, 2002 14:42
Subject: Suggestion
>
> What do people think about a system property switch we can use to
activate/deactivate tests which are "bleeding edge"? Right now, we have
tests (like TestCircularRefs and test/wsdl/gateway) which are in the tree
but test things which are currently known to be broken. The way we deal
with this at present is to comment out the broken stuff so the tests run.
>
> How about instead, we surround "sketchy" things which SHOULD pass but
don't yet with
>
> if (bleedingEdge) {
> }
>
> where bleedingEdge gets set by running with -Daxis.bleedingEdge on the
command line.
> That way people interested in working on making those tests run won't have
to uncomment/recomment various bits and pieces. Once the test works, just
remove the if.
1. please hold back changing buildTests.xml much till I commit the
offline/proxy support, which I am still stabilising (and holding back till
you get 1.1beta out, as it can only break the build)
2. make it an ant property, not a sysprop, so that your own build.properties
can control what is allowed.
3. I like the idea of tests bundled into functional classes, rather than
just 'bleedingedge'...
tests.appserver -httpunit tests
tests.interop -remote interop
tests.performance -load tests; time consuming
tests.broken -anything that is broken, pending classification
With a patternset for each one. This is roughly what I am doing in the
online/offline fix
