On Mon, 20 Sep 2010 22:32:24 +0200, Platonides wrote: > Dan Nessett wrote: >> On Sun, 19 Sep 2010 23:42:08 +0200, Platonides wrote: >>> You load originaldb.objectcache, retrieve the specific configuration, >>> and switch into it. >>> For supporting many sumyltaneous configurations, the keyname could >>> have the instance (whatever that cookie is set to) appended, although >>> those dynamic configurations make me a bit nervous. >> >> Well, this may work, but consider the following. >> >> A nightly build environment (and even a local developer test >> environment) tests the latest revision using a suite of regression >> tests. These tests exercise the same wiki code, each parametrized by: >> >> + Browser type (e.g., Firefox, IE, Safari, Opera) + Database (e.g., >> MySQL, Postgres, SQLite) + OS platform (e.g., Linux, BSD unix variant, >> Windows variant) >> >> A particular test environment may not support all permutations of these >> parameters (in particular a local developer environment may support >> only one OS), but the code mechanism for supporting the regression >> tests should. To ensure timely completion of these tests, they will >> almost certainly run concurrently. >> >> So, when a regression test runs, it must not only retrieve the >> configuration data associated with it, it must create a test run >> environment (e.g., a test db, a test images directory, test cache >> data). The creation of this test run environment requires an identifier >> somewhere so its resources may be reclaimed when the test run completes >> or after an abnormal end of the test run. >> >> Thus, the "originaldb" must not only hold configuration data with db >> keys identifying the particular test and its parameters, but also an >> identifier for the test run that can be used to reclaim resources if >> the test ends abnormally. The question is whether using a full wiki db >> for this purpose is advantageous or whether stripping out all of the >> other tables except the objectcache table is the best implementation >> strategy. > > Such originaldb would be empty for an instance used just for regression > testing and could in fact only contain the objectcache table. If it's a > developer machine he would use the originaldb for local testing, but a > nigthly would not need to (in fact, errors trying to access those > missing tables would be useful for detecting errors in the isolating > system).
Sounds reasonable. Using this approach, here is how I see the logical flow of a test run. (NB: by a test run, I mean an execution of a test in the regression test set). The wiki under test is set up with a master database consisting of a single objectcache table. The entries of this table specify a test run identifier as primary key and temporary resource identifiers as dependent fields. Setup of a test run requires the creation of the test run temporary resources and a entry in the objectcache table. A cookie or other state is returned to the testing application. This state is provided by the testing application during the test run on each request to the wiki under test. When a request is sent to the wiki under test, very early in the request processing (e.g., immediately after LocalSettings is processed) a hook is called with the provided state information as an argument that accesses the objectcache table. The extension function handling the hook switches in the temporary resources and returns. After the test run completes, the testing application cleans up the test run by requesting the deletion of the temporary resources and the objectcache table entry associated with the test run. In order to handle prematurely abandoned test runs, the objectcache table entry probably needs an entry that specifies its lifetime. If this lifetime expires, the temporary resources associated with the entry are reclaimed and the entry is delete. -- -- Dan Nessett _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
