[heft] Increase Jest default timeout from 5s to 15s

[octogonz]

Summary

Some builds were failing randomly because the VM was under heavy load.

[dmichon-msft]

I'm not a fan of doing this globally for all consumers of heft-jest-plugin.

[octogonz]

I'm not a fan of doing this globally for all consumers of heft-jest-plugin.

Why not?

[dmichon-msft]

I'm not a fan of doing this globally for all consumers of heft-jest-plugin.

Why not?

A test taking longer than 5 seconds, even if the VM is under load still indicates a bad test. Alternatively it indicates that you VM's scheduler is running too many processes relative to the number of CPUs, which is a configuration bug.

[octogonz]

A test taking longer than 5 seconds, even if the VM is under load still indicates a bad test. Alternatively it indicates that you VM's scheduler is running too many processes relative to the number of CPUs, which is a configuration bug.

@IanC and @elliot-nelson felt the same way.

After some discussion, we think this error may be revealing an actually incorrect practice for the tests that were timing out:

rushstack/libraries/node-core-library/src/test/Async.test.ts

Lines 168 to 175 in 6380796

	it('returns when given an array with a large number of elements and a concurrency limit', async () => {
	const array: number[] = [];
	for (let i = 0; i < 250; i++) {
	array.push(i);
	}
	await Async.forEachAsync(array, async () => await Async.sleep(1), { concurrency: 3 });
	});

This file contains numerous calls to Async.sleep(1) that although sleeping for "only" 1ms may actually be accumulating into nontrivial delays. Possible improvements:

1. Change them all to Sleep(0)
2. Mock the timers
3. Increase the test limit for just this one file... but how much?

Option 1 seems like the least effort. @dmichon-msft any opinions?