[webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

Ryosuke Niwa rniwa at webkit.org
Mon Jun 4 13:48:25 PDT 2012

On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth <abarth at webkit.org> wrote:

> On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> Are you referring to things like JSValueRef? If JS* functions are
>> supposed to be tested in DumpRenderTree, then that's a good argument
>> against this approach.
> JavaScriptCore has a bunch of tests for its API independent of
> DumpRenderTree.  I suspect Maciej's point is more about having
> DumpRenderTree use public rather than private interfaces so that it's
> easier for JavaScriptCore to change its private interfaces.

My current approach doesn't result in DumpRenderTree using private
interfaces because all binding code will be generated & compiled in
WebCoreTestSupport just like internals.

On Mon, Jun 4, 2012 at 10:51 AM, Sam Weinig <weinig at apple.com> wrote:
> My objects were to adding V8 support to WebKit2, not WebKitTestRunner.

Okay, that's good to know. Thanks for the clarification.

Just to give a bit of history here, the reason I didn't use DumpRenderTree
> for writing a test harness for WebKit2 was that there was no real benefit
> in me doing so.  The requirements of the test harness were quite different
> than they were for a test harness for WebKit1, specifically, we had to
> split functionality between the UIProcess and injected bundle.  In
> addition, DumpRenderTree had become a weird hodge-podge of code, where
> sharing code between projects seemed to be the exception, rather than the
> rule, for instance, I am not sure if the chromium port shares any code in
> DumpRenderTree with other ports (I could be wrong there), and since I was
> binding to a new API, a fresh start seemed the way to go.  All in all, I
> feel it has worked quite well, and has allowed better sharing of code
> between the Qt, Mac, Gtk and Windows WebKit2 implementations.
> That said, I am not sure the current approach taken in WebKitTestRunner is
> fully suited to being merged with DumpRenderTree.  It is quite tied to the
> idea of having two processes and specifically the WebKit2 API.

Yeah, that's the impression I've got as well. It doesn't seem like we can
share much code between DumpRenderTree and WebKitTestRunner other than IDLs.

On Mon, Jun 4, 2012 at 11:13 AM, Sam Weinig <weinig at apple.com> wrote:
> I would not object to the IDL files being shared, as long it doesn't
> introduce additional mental overhead.  Right now, it is pretty simple, and
> I would like to keep it that way.

Would you prefer merging directories for DumpRenderTree and
WebKitTestRunner or create a new intermediary library/project to share IDLs
between the two over moving IDLs to WebCoreTestSupport like I was
originally proposing? (See my patches on
https://bugs.webkit.org/show_bug.cgi?id=88183 and

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

More information about the webkit-dev mailing list