<div dir="ltr">Hi all,<br><br><b>Background</b><br><br>Web Platform Tests is a suite of tests written for <a href="https://github.com/w3c/web-platform-tests/">W3C specifications</a>=,<br>and Blink, Edge, Gecko, and WebKit all run them as a part of their continuous build system.<br><br>Historically, each working group had their own repository for tests,<br>but with <a href="https://github.com/w3c/csswg-test">CSS WG&#39;s tests</a> finally getting merged into the Web Platform Tests,<br>we will have a single repository with all the tests from W3C.<br><br>A few of us attended a <a href="https://docs.google.com/document/d/1lqOBTvaoTUIFuxK0IQL1UfXtybq7Kw8JxBvD6FZSdYE/edit#heading=h.aha7njnu40vz">meeting to discuss the future of this test suite</a> last Monday.<div>One of the major topic was that Blink and Gecko have adopted the process to write the tests</div><div>using testharness.js in their own test suites, and automatically merge into Web Platform Tests</div><div>without having to go through another round of code review for Web Platform Tests.</div><div><br></div><div>Given we do test-driven development in WebKit, I think WebKit should do the same.</div><div>This will benefit other browser vendors to catch their bugs with our tests, and we will also benefit</div><div>from other browser vendors &quot;reviewing&quot; our tests against their implementation and specifications.</div><div><br></div><div>In the long term, I believe this will drastically improve the interoperability of the Web,<br></div><div>and dramatically improve the quality of the tests we run against WebKit.</div><div><br></div><div>In fact, there was a general consensus that we should even upstream pass-if-not-crash tests</div><div>as well as style and layout invalidation tests to web-platform-tests as they tend to be undertested</div><div>right now and almost all engines have bugs in this area.</div><div><br></div><div><b>Problems &amp; Questions</b></div><div><br></div><div>In order to auto-merge tests from WebKit to Web Platform Tests, there are a few problems.</div><div><br></div><div><b>1. We need to start writing more if not all tests using testharness.js instead of our own js-test(-pre).js</b></div><div><br></div><div>I&#39;ve heard of many complaints about testharness.js being too verbose and cumbersome to use.</div><div>I agree with all those complaints but I don&#39;t think we can convince all other browser vendors</div><div>to use our own testing script either since both Blink &amp; Gecko are onboard with using testharness.js</div><div><br></div><div>At this point, I&#39;d argue that the benefit outweighs the cost of adopting testharness.js.</div><div>Also, W3C have dropped many styling requirements for tests so we no longer need to have</div><div>link/meta elements, etc... You simply include testharness.js and testharness-report.js.<br></div><div><br></div><div><a href="https://github.com/w3c/web-platform-tests/commit/c4725e56c91954eaf51759feabec8c6560f10ade">See my recent PR</a> for example.<br></div><div><br></div><div>Do people still object to using testharness.js? If so, what are your reasons?</div><div><br></div><div><br></div><div><b>2. Where should we put upstremable tests?</b></div><div><br></div><div>We need a mechanism to identify &amp; merge tests back from WebKit into Web Platform Tests.<br></div><div><br></div><div>One way to do this is to start adding tests directly into LayoutTests/imported/w3c/web-platform-tests</div><div>and then automatically identify those tests and upstream them.</div><div><br></div><div>Assuming all upstream merges happen in timely happen, this should work fine.</div><div>And it has a benefit that you get to see all related tests in one place.</div><div><br></div><div>Another approach is to create another top-level directory like LayoutTests/exports/web-platform-tests.</div><div>One downside of this approach is that we need to match the directory structure</div><div>in order for any script to upstream tests to appropriate locations.</div><div><br></div><div>Do people prefer one approach over another? Or have another idea?</div><div><br></div><div><br></div><div><b>3. What would be the process for upstreaming tests?</b></div><div><br></div><div>One possible approach is to create a PR request for every patch posted on Bugzilla</div><div>with tests that can be merged into Web Platform Tests.</div><div><br></div><div><div>Because we don&#39;t want to make Web Platform Tests less reliably,</div><div>every PR request to Web Platform Tests go through <a href="https://travis-ci.org/">Travis CI</a></div><div>which runs the test hundreds of times to make sure it&#39;s not flaky.</div><div><br></div><div>This Travis CI job (stability check) will then show up as an additional EWS bubble.</div></div><div><br></div><div><br></div><div>Another approach is to wait until a patch is landed, and automatically create a PR</div><div>for tests that can be upstream&#39;ed. This has a downside that the stability check</div><div>wouldn&#39;t run until the patch is landed, and it&#39;s unclear what happens they do fail.</div><div><br></div><div>Do committers get emails about them? Do the patches then need to be rolled back?</div><div>If we don&#39;t come up with an appropriate process, we can end up with a lot of</div><div>broken PRs that never get fixed like those failing test expectations :(</div><div><br></div><div><br></div><div>Again, do you prefer one or the other? Or do you have another proposal?</div><div><br></div><div>- R. Niwa<br><br></div></div>