On 15.05.12 17:33, Knut Anders Hatlen wrote:
Kristian Waagan<[email protected]> writes:
Hi,
While writing a test for new functionality in the istat daemon I
stumbled across a problem with the DatabaseMetaDataTest (DMDT), which
is being run as part of the upgrade tests.
The problem is that my new test causes entries to be added to various
system tables, for instance SYSFOREIGNKEYS. These rows interfere with
the metadata tests, causing failures. These rows have to exist during
several of the upgrade phases, including those where DMDT is being
run.
I'm assuming disabling DMDT isn't an option.
Does anyone have any good ideas on how to fix this problem?
In my opinion, a fix should be done to DMDT to avoid that other tests
have to care about what DMDT does.
I've tried to change DMDT to operate on its own schema, and that
works.
Using a separate schema sounds like a reasonable way to separate between
DatabaseMetaDataTest's own data and the data of the other tests that run
as part of the upgrade suite.
Thanks for the comments, Knut Anders.
I've created DERBY-5764 ([1]) to track this work.
However, I may have altered some of the metadata searches doing
that, and it required a fair amount of changes to the test (see the
attached patch).
The only queries that change, as far as I can tell, are some calls to
getExportedKeys() and getCrossReference() that used to search all
schemas, and now limit the search to the schema in which the test runs.
They probably still test what they originally intended to test, but
maybe we should at least add tests that exercise the code (call the
methods with the schema parameter set to null and do some light
verification of the result). Just for good measure.
Adding a few additional tests to compensate for the lost coverage sounds
like a good idea. I'll address this in a separate patch.
By the way, could perhaps a ChangeUserSetup be used with a user name
that matches the desired schema name? That might simplify setup and
connection initialization, as the user's schema should be set and
created automatically.
Yes, that works nicely.
I was a bit unsure initially how the various decorators would work in
the upgrade test context. Using a separate database would probably have
worked too, but would have required far more "plumbing code".
Thanks,
--
Kristian
[1] https://issues.apache.org/jira/browse/DERBY-5764
