* rename
* we don't need underscore to check whether an array is empty
* add types, resolve type issues
* remove unused markTop in run.js
* Make the type a little more consistent
* Tweak a check for an empty array
Co-Authored-By: Marcelo T Prado <marceloterreiroprado@gmail.com>
* Add a self-test skip option
Meteor's CI infrastructure is configured to exclude certain
`self-test`'s on each run. These excludes are specified in
each CI environment's config file, and included when running
`meteor self-test`. Developers running `meteor self-test`
locally however are not using these excludes by default,
so developer's have to manually look up the current exclude
list from one of the CI configs, then add these excludes to
their own `meteor self-test` call manually.
This commit adds a new `skip` option to Meteor's `self-test`
system, that can be used to skip adding/running a defined
`self-test` (similar in concept to Mocha's `skip` feature).
This provides a way to skip the running of older
`self-test`'s that are no longer needed, but allows them to
be preserved in the `self-test` suite, for future reference.
With this functionality in place, and the older test suites
updated to use it, Meteor's base CI excludes no longer need
to be maintained in their respective config files. The
excludes are all managed at the source (the test definition),
and can be leveraged by anyone/anything calling
`meteor self-test`.
* Log message describing skipped test
* Add manually-ignored count to self-test summary
* Small comment correction
* History.md entry with PR link
Much of the infrastructure to run "self test" tests (those which test
core functionality of the `meteor` tool itself) in PhantomJS and
BrowserStack was already in place, though the BrowserStack portion had
been disabled some time ago, though the exact reason isn't entirely
clear.
BrowserStack could play an important roll in Meteor's future as Meteor
works to ensure that the bundle delivered to the client is appropriate
for that client's capabilities, including appropriate polyfills to
implement functionality not natively available in the browser (e.g.
ECMAScript features, SockJS, etc.).
Since tests themselves already keep track of their failure, and the test
list (i.e. the `TestList` class) tracks other concepts of grouped tests,
such as "all tests", "filtered tests", etc. (like a `TestList` class
would!) I believe it makes sense for it to also maintain a collection of
"failed tests"... (in list form, of course!)
This will allow the `Run.runTest` logic to move into `run.js` file without
needing to pass back a separate `failed` variable in the event of a
failure, since that is already being tracked through the `notifyFailed`
facility.
