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

[Ojan Vafai]

On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> 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
>
> It's mainly step 2 that I have a problem with, although I also don't like
that the test is not self-contained.

>
>
> 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.
>

Yes, but the point is that it doesn't work to right the tests in the W3C
repo first because what goes in the W3C repo doesn't work for us until we
unprefix our implementation.


>  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.
>

I don't agree, but it doesn't really matter for the current conversation.
We can have this discussion when it actually becomes a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111104/e88ca5e7/attachment.html>