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

[Ryosuke Niwa]

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
https://bugs.webkit.org/show_bug.cgi?id=88200)

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