Throttling in test windows is annoying when tests run interactively,
and *seems* to cause issues with animation frames not firing even in
headless tests, though it’s difficult to fully confirm since this issue
is intermittent.
This doesn't seem to work as expected. I think it's just better to encourage
emitting an event like 'write-to-stdout' or using directly `remote.process`.
/cc: @nathansobo
The idea with this commit is to implement a timeout functionality that does not
rely on a system utility (such as unix `timeout`). Tests could hang because of a
CPU-bound task and, as a result, we need to handle timeouts in a separate
process.
An ideal implementation would first spawn the timeout, which in turn would spawn
the tests, acting as a supervisor and making sure they do not exceed the
supplied time. However, setting up such an environment would have been trickier,
thus the test process spawns the timeout cop before running any test. This, in
turn, invokes a `setTimeout` function and kills the parent process as soon as
the timeout gets triggered, logging to console the reason why the parent process
was killed (and exiting the parent process with code 130).
I haven't used `Task` because, in order to log stuff to the console, we need to
fork the ChildProcess from `remote`, as otherwise nothing gets written out.
If the nearest containing package.json of a test path has an
atomTestRunner field, we’ll require the specified file as a test runner
rather than the default jasmine runner.
