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

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.

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