On Fri, 17 Sep 2010 21:05:12 +0200, Platonides wrote:
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.
The strategy you suggest is reasonable. But, I think it requires significant changes to the parserTests code. The question then is: is it simpler to modify this code or just write something new?