RESOLVED FIXED 109369
[chromium] Enable more of webkit_unit_tests in component builds
https://bugs.webkit.org/show_bug.cgi?id=109369
Summary [chromium] Enable more of webkit_unit_tests in component builds
James Robinson
Reported 2013-02-09 20:53:07 PST
[chromium] Enable more of webkit_unit_tests in component builds
Attachments
Patch (45.74 KB, patch)
2013-02-09 20:58 PST, James Robinson
no flags
with tearoff WebUnitTestSupport interface (50.40 KB, patch)
2013-02-09 22:14 PST, James Robinson
no flags
Patch for landing (116.72 KB, patch)
2013-02-10 17:44 PST, James Robinson
no flags
James Robinson
Comment 1 2013-02-09 20:58:41 PST
WebKit Review Bot
Comment 2 2013-02-09 21:00:06 PST
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
James Robinson
Comment 3 2013-02-09 21:03:13 PST
This adds a number of APIs to Platform that don't make sense for normal operation, but I think the benefits of running more webkit_unit_tests in component builds is worth it. This will compile right now, but without https://codereview.chromium.org/12220091/ the tests won't work.
Darin Fisher (:fishd, Google)
Comment 4 2013-02-09 21:08:17 PST
Comment on attachment 187460 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=187460&action=review > Source/Platform/chromium/public/Platform.h:366 > + virtual void registerMockedURL(const WebURL&, const WebURLResponse&, const WebString& filePath) { } Would it make sense to lump all these methods together behind a tear-off interface? That way, in Chrome we could just make the method to get the tear-off return NULL. > Source/Platform/chromium/public/Platform.h:382 > // Tracing ------------------------------------------------------------- nit: two new lines above section comment
James Robinson
Comment 5 2013-02-09 21:09:23 PST
LevelDBTest.cpp is the one holdout. It uses webkit_support::ScopedTempDirectory / webkit_support::CreateScopedTempDirectory which are thin wrappers around base::ScopedTempDir. This would be possible to plumb this through as well and remove the component/non-component distinction for webkit_unit_tests completely, but that's probably for another patch.
James Robinson
Comment 6 2013-02-09 21:10:21 PST
(In reply to comment #4) > (From update of attachment 187460 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=187460&action=review > > > Source/Platform/chromium/public/Platform.h:366 > > + virtual void registerMockedURL(const WebURL&, const WebURLResponse&, const WebString& filePath) { } > > Would it make sense to lump all these methods together behind a tear-off interface? That way, in Chrome we could just make the method to get the tear-off return NULL. Sure. WebTesting? WebTestingSupport?
Darin Fisher (:fishd, Google)
Comment 7 2013-02-09 21:12:51 PST
(In reply to comment #6) > (In reply to comment #4) > > (From update of attachment 187460 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=187460&action=review > > > > > Source/Platform/chromium/public/Platform.h:366 > > > + virtual void registerMockedURL(const WebURL&, const WebURLResponse&, const WebString& filePath) { } > > > > Would it make sense to lump all these methods together behind a tear-off interface? That way, in Chrome we could just make the method to get the tear-off return NULL. > > Sure. WebTesting? WebTestingSupport? I'd probably go with WebTestingSupport. We have other Web*Support tear-offs.
James Robinson
Comment 8 2013-02-09 22:14:39 PST
Created attachment 187462 [details] with tearoff WebUnitTestSupport interface
James Robinson
Comment 9 2013-02-09 22:15:58 PST
To keep things running, I'll have to: 1.) Check in the Platform/...h changes without the unit test changes so the header is available in chromium 2.) Roll (1) into chromium 3.) Check in chromium implementation of test functions 4.) Roll (3) into WebKit 5.) Check in WebKit/chromium/tests/... changes
James Robinson
Comment 10 2013-02-09 22:21:57 PST
(In reply to comment #9) > To keep things running, I'll have to: > Slight refinement: 1.) Check in the Platform/...h changes without the unit test changes so the header is available in chromium with #define HAVE_WEBUNITTESTSUPPORT 2.) Check in chromium implementation with #include/etc guarded by #if HAVE_WEBUNITTESTSUPPORT 3.) Wait for (1) to roll into (2), roll (2) into WebKit 4.) Check in WebKit/chromium/tests/... changes 5.) Remove #define and #ifs at leisure
James Robinson
Comment 11 2013-02-09 23:11:16 PST
James Robinson
Comment 12 2013-02-09 23:12:07 PST
(In reply to comment #11) > Committed r142388: <http://trac.webkit.org/changeset/142388> This is the Platform API, still need to land the chromium side + roll it in + land the actual unit test changes.
James Robinson
Comment 13 2013-02-10 16:10:36 PST
The chromium side change has rolled in, but in local testing I'm finding many of the tests that will now start running in debug+component builds are flaky or buggy. It seems that pretty much none of the tests in WebFrameTest.cpp clean up properly. I guess this is somewhat expected given that they haven't run on any bots in debug mode in forever :/
James Robinson
Comment 14 2013-02-10 17:44:37 PST
Created attachment 187500 [details] Patch for landing
James Robinson
Comment 15 2013-02-10 17:45:20 PST
(In reply to comment #14) > Created an attachment (id=187500) [details] > Patch for landing http://www.youtube.com/watch?v=FONN-0uoTHI
WebKit Review Bot
Comment 16 2013-02-10 18:39:45 PST
Comment on attachment 187500 [details] Patch for landing Clearing flags on attachment: 187500 Committed r142422: <http://trac.webkit.org/changeset/142422>
WebKit Review Bot
Comment 17 2013-02-10 18:39:50 PST
All reviewed patches have been landed. Closing bug.
Tony Chang
Comment 18 2013-02-11 12:59:08 PST
This is great. Thanks for doing this.
Note You need to log in before you can comment on or make changes to this bug.