[webkit-dev] Supporting w3c ref tests and changing our convention

[Ryosuke Niwa]

On Fri, Nov 4, 2011 at 6:31 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Fri, Nov 4, 2011 at 5:52 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>> W3C's build step auto-generates them.
>>
>
> I thought you were arguing that we should use manifest files for all
> reftests because having multiple ways to do things is confusing.
>

I am, but I'm particularly concerned about W3C tests. It'll be nice if we
had exactly one way of running / writing ref tests. I think we can easily
automate the process of generating manifest files.

The work flow will be as follows:

   1. Write new ref tests using link element
   2. Run some tool (maybe we can teach run-webkit-tests to do it
   automatically)
   3. Upload patch with auto-regenerated manifest file

But we don't need to structure them. They're organized in W3C's repo, and
>> we're just going to import them in some directory; e.g. LayoutTests/w3c/.
>>
>
> I'm reluctantly OK with doing this exclusively for test suites we import
> that come with a manifest file, since the maintenance cost is lower.
> Although, I'd prefer if we limited the number of ways you could mark a test
> as a reftest.
>

Yeah, I won't be particularly happy about having two ways to write ref
tests.

If we're adding new tests that we intend to contribute back to W3C, then
>> those tests should live outside of this directory. The preferred
>> approach, however, is to add tests to W3C repo first, then import them back
>> to WebKit.
>>
>
> I don't think this is realistic. For example, for the new flexbox tests,
> we're writing them against WebKit's code and they're changing as we go. In
> addition, all the properties are webkit prefixed. We're not writing test
> suites in isolation. We're writing them as we implement the feature or fix
> the appropriate bugs.
>

Right, but then you'll need to unprefix those tests and reformat them in
order to upstream the tests anyway.

 I don't see what's special about reftests that we'd run them on a separate
>>> bot. We might decide to shard test running across different bots in some
>>> way, but sharding by test type seems unhelpful.
>>>
>>
>> I'm not talking about ref-tests. I'm talking about tests imported from
>> the W3C test suite.
>
>
> Even then, I don't see any benefit to not running them as part of our main
> test suite.
>

It all depends on the number of tests. CSS 2.1 test suite appear to contain
10,000+ tests (there are 10,000+ .xht files). If we're adding CSS3, and
other test suites from W3C, it can easily be in the order of 100,000s given
that W3C is trying to increase the number of tests significantly in the
coming years.

Given we spend 10+ minutes running 26,000+ layout tests on our bots, adding
100,000+ tests will result in quadrupling our bot cycle time (to 40-50+
minutes; or to 3-4 hours for any bots that run pixel tests). It's
definitely nice if we could run them all on the main waterfall with our
regression tests, but slowed cycle time may significantly hinder our
ability to catch new test failures on time.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111104/8a3b644c/attachment.html>