Thanks Dan for working on this.
Daniel John Debrunner wrote:
I'm looking at this approach as a quicker way to moving to a single
(JUnit based) test infrastructure.
+1.
While canon based tests are not ideal, I think they are acceptable as
an interim step, especially if we manage to switch to a single
infrastructure. A good goal would be to have the 10.3 release (mid
year?) with a single infrastructure so that bug fixing and text cases
are easy to merge between trunk and 10.3. Also running the tests in
this way does not stop anyone from converting an individual test, it
makes it no harder. In fact it *might* make it easier, as a it might
be possible to incrementally convert tests and have them continue to
run with a master file.
One benefit I see from this approach is that it may allow the
community to focus on converting tests that cannot be run using this
or other adapters, for example ones with multiple canon files, per jvm
version for example. Those tend to be the tests that occupy the most
time as the need to update multiple canons is costly.
I agree with this. In my own experience -- I have spent quite some
time trying to update the testSecMec test :) for different jcc
versions/jdk versions that I think it might be greater benefit/worth for
the community to focus on such multiple canon files test to be converted
first.
It will also centralized which environments a test runs in, one of the
issues I'm seeing with the jdbcapi tests and client server is trying
to figure out if a test is meant to run in c/s or not. Not clear from
the old harness setup.
Can you elaborate more on this. I am thinking you mean that once we
move to Junit harness (using the adapters or otherwise) , it would be
cleaner to know which environment it is run. When we convert the test
using the adapter, we do have to do some work to find out if the test
should be run in client /server mode or not. Is that right ?
Thanks,
Sunitha.
