Dan Nessett wrote:
Given this background, consider the following (and
feel free to comment
on it):
parserTests temporary table code:
A fixed set of tables are specified in the code. parserTests creates
temporary tables with the same name, but using a different static prefix.
These tables are used for the parserTests run.
Problems using this approach for selenium tests:
+ Selenium tests on extensions may require use of extension specific
tables, the names of which cannot be elaborated in the code.
The extensions could list their table names. No problem there.
+ Concurrent test runs of parserTests are not
supported, since the
temporary tables have fixed names and therefore concurrent writes to them
by parallel test runs would cause interference.
So it gets changed to a random name with a fixed prefix...
What concerns me is
+ Clean up from aborted runs requires dropping fossil
tables. But, if a
previous run tested an extension with extension-specific tables, there is
no way for a test of some other functionality to figure out which tables
to drop.
Run a script dropping all tables with a fixed prefix (the shared part of
the tests) when you have no tests running.
For these reasons, I don't think we can reuse the
parserTests code.
However, I am open to arguments to the contrary.
There may be other issues with that code, and using a separate db would
be preferable if you have enough permissions, but this doesn't seem like
real problems.
What concerns me is that Oracle is using (r58669) a different prefix for
the parsertests table. If it has some restriction on [medium-large]
table names, there may not be possible to run the tests there using the
long table names that we could produce.