[webkit-dev] removing js-test-post.js WAS: Can we distinguish imported tests in LayoutTests/css3 ?
ojan at chromium.org
Tue Jun 12 10:31:56 PDT 2012
On Tue, Jun 12, 2012 at 10:18 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 12.06.2012, в 9:59, Ojan Vafai написал(а):
> One more item I'd add to this list:
> -Replace js-test-post.js with an onload handler in js-test-pre.js so we
> can get rid of that file entirely.
> I think that this is a separate discussion to test directory
Makes sense. Changed the subject. Seemed related to me in that it might
simplify moving tests that include it.
> Also, I'd question that "getting rid" of some boilerplate in autogenerated
> code is a worthy goal, given that it will make tests more fragile.
I'm sympathetic to this argument. In this case, the only way it makes the
tests more fragile is that it makes them depend on us firing the onload
event. I feel like so many things would break if you break onload, that
it's not really making the tests more fragile in practice.
Increasingly, js-test-pre.js is not being used by autogenerated code. This
is something we should encourage. By standardizing on this for most
dump-as-text tests, we simplify test code and simplify making sense of test
failures (e.g. you don't need to understand the custom test harness in the
test to figure out a failure). We should only use autogenerated
script-tests for cases where we need to isolate out the pure JS code (e.g.
pure JS tests or tests that need to be run both inside and outside a
Worker) since they add the extra overhead of dealing with an extra file and
need the extra work of running the autogeneration script.
In practice, what happens right now is that people often leave out
js-test-post.js and you lose a significant bit of the test harness's
functionality (i.e. checking for unintentional parse errors).
The benefits far outweigh the risks here IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev