On Feb 21, 2012, at 12:15 PM, Ryosuke Niwa <[email protected]> wrote: > It appears to me window.internals is a superior solution to expose > cross-platform features to our test harness compared to other interfaces > implemented in DumpRenderTree and WebKitTestRunner such as > layoutTestController and friends.
As the name implies, the internals object is a good way to expose WebCore internals to JavaScript so they can be tested in our regression test harnesses. Pros for internals: - Cross-platform; only has to be done once rather than once per platform. - Cross-JavaScript-engine. Based on DOM JavaScript binding machinery. - Easier to do the JavaScript binding aspect, because it’s based on IDL rather than hand-written. - In WebCore itself; no need to first marshal things across to WebKit just so the test tools can then expose them to JavaScript. - Separate library is a good technique to keep the test code out of production builds. Cons for internals: - Tests only WebCore, not the platform-specific WebKit API/SPI layer. - Requires a copy of the internals library that is identically versioned with the WebCore library being tested. - Not suitable for control of the testing machinery itself. > Should we try to move methods of layoutTestController and friends that expose > WebCore-level features to internals? Yes. We should move functions or attributes on layoutTestController that are not about control of testing, but simply about exposure of internals to be tested. We should not move functions or attributes that are about controlling the test machinery nor should we necessarily move test harnesses such as eventSender. Also, there are some functions and attributes that helpfully test WebKit in addition to WebCore. While those don’t really belong on a “test controller” object, moving them to internals would remove the testing of WebKit. We can think more on what to do about those. It is a little unfortunate that this helpful direction is likely to make us test WebCore more thoroughly at the cost of losing test coverage for the WebKit layer. -- Darin _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
