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

Darin Fisher darin at chromium.org
Sun Jun 10 22:53:41 PDT 2012

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


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

More information about the webkit-dev mailing list