We appreciate the thoroughness, but we think it's OK to _not_ have this
level of meta-testing at this point in the project.
Co-authored-by: Antonio Scandurra <as-cii@github.com>
In earlier commits from this PR, some breaking changes were done to the
WinShell module, which cause some issues on the `settings` package (and
potentially other packages).
Since these breaking changes are not needed (and they don't provide even
a better API), this PR reverts them to keep the previous contract.
Before, in order to retrieve the application name, Electron's
`getName()` method was used (https://electronjs.org/docs/api/app#appgetname).
Now, instead, we also use the Atom version in order to calculate the release
channel and be able to have it on the app name (e.g `Atom Nightly`).
Since ChromeDriver v2.41, ChromeDriver will only connect if, either we precise a port
for remote debugging, either the embedder (ie electron) made sure to pass `USER_DATA_DIR`
to the remote debugging server.
So, for now, we'll just use a random port (we don't care about its value since we're not
connecting through it).
(inspired by 737db138bd).
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)).
