FilesApp FileDialog browser test takes too long |
|||
Issue descriptionThe FileDialog browser test should be split it into three separate tests. The current test loads the open file dialog _three times_ in each test fixture to test: - clicking the file dialog ok button - clicking the file dialog cancel button - sending the file dialog an ESC key This makes the test-time long, which leads to persistent TIMEOUT-PASS flakes on the (slow) DEBUG/ASAN/MSAN bots. By splitting the test into three parts, flakes will be mostly eliminated, and overall run-time of FileDialog browser tests _will be reduced_ [1] even though there are more test cases. [1] TIMEOUT-PASS flakes cause a test to run again, effectively doubling the test-time of the FileDialog browser tests.
,
May 21 2018
Long test-time flirts with the MSAN/ASN/DEBUG bot time-out limits, which gets hit too often (due to whatever other browser tests the bot is running at the time).
,
May 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e63f0a4fd560818c396a518b37ab5f37876533f0 commit e63f0a4fd560818c396a518b37ab5f37876533f0 Author: Noel Gordon <noel@chromium.org> Date: Mon May 21 06:11:52 2018 Deflake FileDialog browser test: split it into separate test cases Split the test for Ok button, Cancel button, ESC key, closing the open file dialog into separate test cases. Formerly the test tried to do all three per test case, but that causes persistent TIMEOUT-PASS flakes on MSAN/ASAN/DEBUG bots [1]. Splitting the test into separate test cases will shorten the test-time and hopefully minimize TIMEOUT-PASS flake likelihood on those bots. FileDialog is not supported in Mash, so add Mash bot filter exclusions for the new tests added in this change-set: FileDialog/FilesAppBrowserTest.Test/openFileDialogCancelDrive FileDialog/FilesAppBrowserTest.Test/openFileDialogEscapeDrive FileDialog/FilesAppBrowserTest.Test/openFileDialogCancelDownloads FileDialog/FilesAppBrowserTest.Test/openFileDialogEscapeDownloads [1] See crbug.com/845054#c2 Test: browser_tests --gtest_filter="FileDialog/FilesApp*" Bug: 845054 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: Idaa629727fb78babe96a51d4e0b89e43fb9abc97 Reviewed-on: https://chromium-review.googlesource.com/1065718 Commit-Queue: Noel Gordon <noel@chromium.org> Reviewed-by: Naoki Fukino <fukino@chromium.org> Reviewed-by: Tomasz Mikolajewski <mtomasz@chromium.org> Cr-Commit-Position: refs/heads/master@{#560236} [modify] https://crrev.com/e63f0a4fd560818c396a518b37ab5f37876533f0/chrome/browser/chromeos/file_manager/file_manager_browsertest.cc [modify] https://crrev.com/e63f0a4fd560818c396a518b37ab5f37876533f0/testing/buildbot/filters/mash.browser_tests.filter [modify] https://crrev.com/e63f0a4fd560818c396a518b37ab5f37876533f0/ui/file_manager/integration_tests/file_manager/file_dialog.js
,
May 21 2018
,
May 22 2018
Ahem, making Files.App browser tests faster, more focussed, can way improve the flake situation, and that improves the lives of chromium developers in general. A reading from the Flakiness Dashboard after #6, for browser test: FileDialog/FilesAppBrowserTest.Test/openFileDialogDownloads
,
May 22 2018
Before shot #2, after shot #9, bye bye persistent bot flakiness. |
|||
►
Sign in to add a comment |
|||
Comment 1 by noel@chromium.org
, May 21 2018