<div class="gmail_quote">On Tue, Jun 12, 2012 at 10:18 AM, Alexey Proskuryakov <span dir="ltr"><<a href="mailto:ap@webkit.org" target="_blank">ap@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><br><div><div>12.06.2012, в 9:59, Ojan Vafai написал(а):</div><div class="im"><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

One more item I'd add to this list:</div><div>-Replace js-test-post.js with an onload handler in js-test-pre.js so we can get rid of that file entirely.</div></span></blockquote></div></div><div><br></div><div>I think that this is a separate discussion to test directory reorganization.</div>

</div></blockquote><div><br></div><div>Makes sense. Changed the subject. Seemed related to me in that it might simplify moving tests that include it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div>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.</div></div></blockquote><div>

<br></div><div>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. </div>

<div><br></div><div>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.</div>

<div><br></div><div>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).</div>

<div><br></div><div>The benefits far outweigh the risks here IMO.</div><div><br></div><div>Ojan</div></div>