[webkit-dev] Test conversion to use W3C testharness.js

[Alan Stearns]

I’m told that changes to the file are meant to be backwards-compatible. The API should not change, except to add new methods.


On 3/9/12 2:28 PM, "Jacob Goldstein" <jacobg at adobe.com> wrote:

I recently uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an existing JavaScript regions parsing test to use the W3C testharness.js in place of js-test-pre.js/js-test-post.js.  This patch also places testharness.js and a WebKit-specific testharnessreport.js file in LayoutTests/fast/js/resources.

In cases where tests need to be written for both the WebKit and W3C testing suites, having the ability to use testharness.js with WebKit tests would mean that the test file only needs to be written once, and yet can still rely on the functionality from both test harnesses.   As it stands now, if someone needs to write a test for both suites, they either have to implement all functionality from scratch, or write one version of the test to use js-test-pre.js and another to use testharness.js.  The inclusion of testharness.js in the WebKit repository alleviates the need for this duplication of effort.  The testharnessreport.js file was intended for customization of the capabilities provided by testharness.js, I've added a call to layoutTestController.dumpAsText() to this file to allow it to function as a WebKit JavaScript test.

There is some potential issues that I wanted feedback on.

testharness.js uses a css file to format the test output.  The path to this css file is assembled by the script.  For the time being, I have not included the css file in the patch I attached to 80709.  The CSS file has no impact when testharness.js is used along with dumpAsText as I have in the test I converted.  It may provide some value, but I am going to suggest to the W3C that the CSS styling of results should move from testharness.js to testharnessreport.js (where it can be overridden).

Another concern is that changes to testharness.js in the future that break backward compatibility could then break WebKit tests.  This is an issue I plan to discuss with W3C members to determine if backward compatibility can be ensured.

I'd appreciate any thoughts or feedback people have on this issue.

Thanks,
Jacob

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