- From: James Graham <james@hoppipolla.co.uk>
- Date: Tue, 17 Sep 2013 13:13:02 +0100
- To: public-test-infra@w3.org
On 17/09/13 13:07, James Graham wrote: > On 17/09/13 12:58, Tobie Langel wrote: >> On Tuesday, September 17, 2013 at 10:55 AM, James Graham wrote: >>> On 16/09/13 18:37, James Graham wrote: >>> >>>> Good question. The easiest (hacky) way is to regenerate the local >>>> testharnessreport.js file for the testrun. However that only works if >>>> the multiplier (or equivalent) is fixed for the entire run. Supporting >>>> per-test overrides in this way would work in the absence of >>>> parallelisation, or with one test server per instance, but neither of >>>> those sound ideal. However the only way I can think of to pass in the >>>> timeout so that it is avaliable before any script has loaded is via a >>>> query parameter, which is something that I have traditionally resisted >>>> commandeering. >>> >> >> In general, this doesn't bother me as much as it bothers you; I see >> query params as the equivalent of params in a CLI. > > Having thought more about it I still need some mechanism to pass in a > per-test timeout multiplier; although I could disable these entirely it > would have bad effects if one test in a large set is badly-behaved since > it could prevent the timeout running. s/timeout/subsequent tests/ Sorry.
Received on Tuesday, 17 September 2013 12:13:32 UTC