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

[Jochen Eisinger]

On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>
>> I've implemented initial support for running layout tests using
>> chromium's content_shell instead of test_shell as the current DRT
>> implementation does. It's still a very experimental, but might already be
>> interesting for some of you to try.
>>
>
> This is great! Thanks a lot on working this.
>
> 1. Make sure your WebKit is at least at r119852 (see
>> http://trac.webkit.org/wiki/Chromium for prerequisites)
>> 2. Apply the attachment from
>> https://bugs.webkit.org/show_bug.cgi?id=87045
>> 3. In Source/WebKit/chromium run gclient sync
>> 4. build webkit as usual
>>
>> E.g. for a debug build on Linux, this should give you
>> out/Debug/content_shell
>>
>> You can now run layout tests like this:
>>
>> new-run-webkit-tests --chromium --debug --driver-name=content_shell
>> --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/*
>>
>> You'll notice that not all tests are passing yet, mainly because not all
>> (or actually, almost none of the) layoutTestController features are
>> implemented yet.
>>
>
>  Where is layoutTestController implemented? We definitely need to move the
> implementation of layoutTestController, eventSender, etc... into WebKit
> repository because we often rename functions, etc... in WebKit. It's
> unacceptable to require having to modify Chromium code in order to do this
> refactoring in the future.
>

It's currently here:
http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.js&exact_package=chromium

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

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