Prior to this change, the `console.error` statement _always_ ran,
regardless of whether the promise resolved successfully. With this
change, we clear the timeout in the scenario where the promise resolves
successfully.
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
If multiple specs were to populate the events var, one spec would
pollute the others. So, let's reset the events var at the beginning of
each spec.
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
Prior to this change, the spec was using the fake clock, which was
preventing the `setTimeout` from ever calling the `expire` function.
Co-Authored-By: Antonio Scandurra <as-cii@github.com>
On Azure and Travis, we recently started observing a few test failures
in atom-application.test.js.
After staring at those tests for a bit, it doesn't seem like they are
failing due to a race condition. Instead, it is possible that these
tests are simply timing out due to CI containers sometimes being
overloaded and, thus, slower. I tested this hypothesis locally by
running tests on a VM while stress-testing the host machine. Tests would
eventually have passed, but they timed out before having the chance to
do so.
This commit increases the timeout on CI to 10 seconds for
`AtomApplication` tests in an attempt to fix the spurious failures we
were observing. This is similar to what we've historically done for
renderer process tests (see
7faea50190/spec/spec-helper.coffee (L50)).
Previously, we would wait for the next update promise after resizing the
editor as an indicator of when the resize occurred. Unfortunately,
resize events are unreliable and may not be emitted right away. This
could cause the test code to wait for an update promise that was
unrelated to the resize event (e.g., cursor blinking).
This commit uses a condition-based promise that ensures the rendered
rows have changed as a result of the resize. This seems to fix the issue
locally when introducing artificial timeouts in the resize event.
In these tests, we create a temporary `ATOM_HOME` to avoid cluttering
the user's real `~/.atom` folder.
Adding a symlink to the real `compile-cache` was introduced to speed up
main process tests, so that the transpilation cache could be reused.
Unfortunately, when the real `~/.atom` folder did not exist (such as on
a pristine environment on CI), it would confuse Atom, which would think
that it didn't need to re-create a `compile-cache` folder again, but
wouldn't be able to write to it because the symlink pointed to a
non-existant directory.
Main process tests were overhauled and made faster recently, so we can
safely remove this performance optimization.
That logic was only needed to make `ripgrep` match correctly globs like
`src` when we pass it the folder to search on.
If we don't pass the folder, `ripgrep` assumes it's the cwd and their
glob matching logic improves by allowing globs like `src`.
