Investigate long running JavaScript tests (top 10 over 1 second)
Our Karma tests run in about a minute in total. However the median for a single test (of the roughly 3000) is one millisecond. So half of the tests take roughly 98% of the time. The top 10 longest running tests take up 50% of the time.
I have tested this by adding the following to test_bundle.js
:
beforeEach(() => console.time('test duration'));
afterEach(() => console.timeEnd('test duration'));
Then I ran DEBUG=1 yarn karma
and filtered the output with
grep -oE 'test duration: \d+' chrome_debug.log | cut -d ' ' -f 3 | sort -n
By adding the following to test_bundle.js
I was able to identify the longest running tests:
let testStarted;
beforeEach(() => {
testStarted = new Date();
});
afterEach(() => {
const now = new Date();
if (now.getTime() - testStarted.getTime() > 999) {
fail('too long!');
}
});
-
Issuable Time Tracker Content Display Panes Help pane should not show the "Help" pane when help button is clicked and then closed
-
MergeRequestTabs loadDiff with inline diff with note fragment hash should gracefully ignore non-existant fragment hash
—may be related to https://gitlab.com/gitlab-org/gitlab-ce/issues/35294
-
Notes updateNote updates note and resets edit form
-
Notes postComment & updateComment should remove placeholder note when new comment is done posting
-
Notes postComment & updateComment should show actual note element when new comment is done posting
-
Notes postComment & updateComment should reset Form when new comment is done posting
-
Notes postComment & updateComment should show flash error message when comment failed to be updated
-
Notes postComment with Slash commands should remove slash command placeholder when comment with slash commands is done posting
-
Notes update comment with script tags should not render a script tag
-
Shortcuts toggleMarkdownPreview focues preview button inside edit comment form
-
SmartInterval Increment Interval should not increment past maxInterval
: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20496
We should take a look at those tests because they likely contain bugs or can be split into smaller tests. If we can half the time for running frontend tests, we safe a significant amount of developer time and increase motivation to run tests locally.
After talking care of above mentioned tests, we can fail tests that take longer than a second and reiterate.