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

[Darin Fisher]

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:
>
>> 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
>
>
^^^ This second solution seems like it will work well.  It will enable the
guts of layoutTestController to remain in the WebKit repository.  This is
just a variation of exactly what we do today.  You only need to move
creation of WebView to Chromium so that we can eliminate WebViewHost.cpp
(and other "simple" application shell bits).

-Darin



> best
> -jochen
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120610/b97f2360/attachment.html>