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.

Edited Jul 09, 2018 by Inactive Account
Assignee Loading
Time tracking Loading