[webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

[Ryosuke Niwa]

On Fri, Jun 8, 2012 at 1:09 PM, Jochen Eisinger <jochen at chromium.org> wrote:

> On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>>
>>>  On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>
>>>> Per my other thread about sharing IDLs between DumpRenderTree and
>>>> WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
>>>> instead of adding yet another binding code.
>>>>
>>>> Another missing feature is producing pixel results. However, I'm
>>>>> currently concentrating on text results, as I think the biggest benefit is
>>>>> the ability to run storage tests on the real storage implementation.
>>>>>
>>>>
>>>> That sounds great to me but we definitely need to support pixel results
>>>> eventually. I'm more than happy to help you on that but that requires the
>>>> codebase to be moved into WebKit repository.
>>>>
>>>
>>> Here's the basic problem: content_shell depends on content, so moving
>>> this on the webkit repository would mean that webkit depended on content.
>>>
>>> Another solution would be to formalize the test shell API our current
>>> layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and
>>> add a method to chromium's webkit support library that returns a webview
>>> that supports all the hooks required. The webview could then either be
>>> implemented by test_shell or by content_shell
>>>
>>
>> I don't know any architectural details of content_shell so it's hard for
>> me to comment on this matter, but I don't see a problem in
>> WebKitChromiumTestRunner (hypothetical name to be consistent with
>> WebKitTestRunner) depending on content_shell given that WebKitTestRunner
>> also depends on WebKit2 API.
>>
>
> Today, when somebody adds e.g. a new callback to LayoutTestController,
> they can just patch DumpRenderTree. If our test runner lived (in large
> parts) in chromium's repository, such a change would require a patch to
> chromium. This would either put an additional burden on all WebKit
> developers, or our test runner constantly gets out of sync.
>

Yes, that's why I'm suggesting that this new test runner needs to be in the
WebKit repository. It's not acceptable to require WebKit contributors to
modify code in the Chromium repository in order to refactor or add or
remove features to the test runner.

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