Rebaselining may add new all-PASS baselines for testharness.js tests. |
|||||
Issue descriptionFor testharness.js tests where all tests pass, we don't keep baselines. Currently, if a baseline (with some FAIL lines or console errors) exists for a testharness.js test, then a change is made which results in all test methods passing, then the baseline should be deleted, rather than updated to include only PASS lines. The simplest fix for this may be to check new downloaded baselines after downloading them (maybe in rebaseline-test-internal?), and if they are all-pass testharness baselines, delete them.
,
Oct 7 2016
,
Oct 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0bb11a3670a64f56774881350f8f4b0035ba2eeb commit 0bb11a3670a64f56774881350f8f4b0035ba2eeb Author: qyearsley <qyearsley@chromium.org> Date: Tue Oct 11 19:21:07 2016 When rebaselining testharness tests with new all-PASS results, remove the baseline. For testharness.js tests where the result just contains PASS lines with no console errors or warnings, our way of representing that is to have no baseline (no -expected.txt file). So, when rebaselining, the proper "baseline" for tests like this is to have no baseline. Example case for how I think this might work: Let's imagine there's a testharness test which fails on mac and linux, but passes on windows. The existing baselines may be: LayoutTests/platform/mac/foo/bar-expected.txt LayoutTests/platform/linux/foo/bar-expected.txt If we rebaseline and it now passes on linux, then I imagine that the copy-existing-baselines baselines step would copy linux/foo/bar-expected.txt to linux-precise/, and the baselines in both linux/ and linux-precise/ would be deleted on the rebaseline-test step. Then, we'd be left with just LayoutTests/platform/mac/foo/bar-expected.txt. Although I haven't really tested out this whole flow yet. This CL also extracts a function import is_all_pass_testharness_result from webkitpy.layout_tests.models.testharness_results to avoid duplicating code. BUG= 654030 Review-Url: https://codereview.chromium.org/2409903002 Cr-Commit-Position: refs/heads/master@{#424509} [modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/check-testharness-expected-pass [modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/models/testharness_results.py [modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/models/testharness_results_unittest.py [modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline.py [modify] https://crrev.com/0bb11a3670a64f56774881350f8f4b0035ba2eeb/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_unittest.py
,
Oct 11 2016
,
Oct 12 2016
When I ran webkit-patch rebaseline-cl --only-changed-tests for a CL that changed a testharness test so that it was all-PASS, the baselines were deleted as expected.
,
Oct 23 2016
In the latest runs of w3c-test-runner, it appears that there's a case where there's an old non-platform-specific non-all-PASS baseline, and rebaselining should remove it the generic baseline, but it is not being removed. Specifically, for these tests: imported/wpt/custom-elements/reactions/Document.html imported/wpt/custom-elements/reactions/NamedNodeMap.html imported/wpt/html/semantics/embedded-content/media-elements/interfaces/TrackEvent/constructor.html In try jobs for https://codereview.chromium.org/2442983002.
,
Oct 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad commit 8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad Author: qyearsley <qyearsley@chromium.org> Date: Tue Oct 25 21:13:40 2016 Remove all all-PASS testharness baselines after rebaselining. In http://crrev.com/2409903002 I added logic to webkit-patch rebaseline-test-internal so that when rebaselining particular tests, all-PASS testharness.js test baselines would be removed. Later, I discovered that if a generic non-all-PASS baseline already exists, it won't be removed when rebaselining, so that approach doesn't quite solve the problem. In general, we don't want any all-PASS baselines for testharness.js, so this CL takes a different approach: After rebaselining, enumerate all relevant baselines, and remove any all-PASS testharness.js baselines. Removing such a baseline should never be incorrect. BUG= 654030 Review-Url: https://codereview.chromium.org/2445963002 Cr-Commit-Position: refs/heads/master@{#427470} [modify] https://crrev.com/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline.py [modify] https://crrev.com/8a567b64e5bbed2d0f2c0cfdbce6e291b5d669ad/third_party/WebKit/Tools/Scripts/webkitpy/tool/commands/rebaseline_unittest.py
,
Nov 2 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by qyears...@chromium.org
, Oct 7 2016