<div dir="ltr">On Sun, Feb 5, 2017 at 5:04 PM, youenn fablet <span dir="ltr">&lt;<a href="mailto:youennf@gmail.com" target="_blank">youennf@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I too am a big proponent of us moving more and more towards WPT.<div>As part of the streams and fetch API implementation, most of the related functional tests have been made as WPT.</div><div>The benefits of having tests being improved and updated largely outweighs the testharness.js initial cost.</div><div>Somehow, these tests are becoming part of their related specs.</div><div><br></div><div>The two complaints I heard against testharness.js are:</div><div>- They are less easy to debug as test harness.js does not print out messages for each assert. There might be room for updating testharness to support that<br>- Async tests are less easy to write. While this is probably true, testharness has support for promise-based tests which are not verbose.</div><div>WPT has also some benefits of its own, like the possibility to run easily the same tests in worker/window environments, the flexible python-based server...</div><div><br></div><div>One complaint I heard against WPT tests is that they require being run behind a server.</div><div>This is becoming more and more true. </div><div>There is still a large portion of tests that could be run locally if we update the paths to test harness.js/testharnessreport,<wbr>js.</div><div>I am not a big fan of modify any WPT test but maybe we should consider switching back to modifying these paths at import and export time.</div></div></blockquote><div><br></div><div>We should probably do this for the sake of making tests more debuggable. Having to run a HTTP/HTTPS server makes testing WebCore against a test needlessly harder especially for things like core DOM API which doesn&#39;t require any network stack.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I would tend to do the following:</div><div>- Write/submit WPT tests in WebKit as regular WebKit testharness.js layout tests through bugzilla</div><div>- At commit queue time, automatically create a PR to WPT GitHub containing the changes of the WebKit patch<br></div></div></blockquote><div><br></div><div>I think commit queue time is too late. Remember that not everyone uses commit queue. Also, if there was any issue with a test, we should be able to tell that prior to landing the patch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>- Ask committer to fix the WPT PR should there be any issue with it (committer being informed of such issues through bugzilla).<br></div></div></blockquote><div><br></div><div>I think this is too much of an overhead / a burden for WebKit contributors. Now patch contributors need to worry about EWS, <a href="http://build.webkit.org">build.webkit.org</a>, and some random PR that gets created on Github failing.</div><div><br></div><div>The fact people have to worry about EWS &amp; <a href="http://build.webkit.org">build.webkit.org</a> separately is bad enough. We shouldn&#39;t be introducing yet another place people have to monitor / care about.</div><div><br></div><div>- R. Niwa</div><div><br></div></div></div></div>