Don't ignore files starting with '_'
Ignore files starting with '_'
Fix path for fixtures
Add 'fixtures' path to tests
Move ignored fixtures to their own directory
Use the source-map-fixtures package to provide a fixture which throws an error.
Stack traces should be corrected for this fixtures.
Add a script to generate a test fixture that comes with an input source map.
Errors from this fixture should be mapped to the input source. Having the script
makes it easier to update this fixture in the future.
The generated fixture now uses a source map file. Commenting out the
inputSourceMap code in lib/babel.js didn't cause the test to fail if an inline
source map was used. I'm not sure why that is. The test fails as expected when
using a map file.
Note that the original 'stack traces for exceptions are corrected using a source
map' test only tested the source map cached by lib/babel.js. This is already
covered by the new 'stack traces for exceptions are corrected using a source
map, taking an initial source map for the test file into account' test.
We throw the error from another fixture which uses a source map file. This
implicitly tests source-map-support. We're not testing a fixture which uses an
inline source map, firstly because that's somewhat superfluous and secondly
because the generated stack trace line is deemed not important due to the
logger's behavior and a source-map-support bug
(<https://github.com/evanw/node-source-map-support/pull/119>).
There were two problems with using destructuring on the `t` parameter
passed to tests:
1. `t.end` is enumerable, but throws when accessed. This created
problems when destructuring using rest params `{ok, ...t}`.
The solution: `t.end` is enumerable only in "callback mode".
2. `t._capt`, `t._expr` are not enumerable, and therefore not
exposed as a member of the `...t` rest param.
The only solution was to make them enumerable.
Not ideal, but better than the confusing error that previously occurred.
Nothing wrong with the implementation, but the test was only
checking test duration, not that the test passed. The test
was incorrecty using `t.end`, and so finished quicker than expected.
AVA will no longer automatically end tests when you reach the plan limit.
Users must explicitly call t.end().
It is now an error to return an async object (promise/observable) from
a legacy `test.async` test.
Reference:
https://github.com/sindresorhus/ava/issues/244#issuecomment-159348943
Accessing `t.end` now throws an error unless the test is first
declared async via `test.async([title], fn)`
Reference:
https://github.com/sindresorhus/ava/issues/244
(cherry picked from commit 28b1641)
Initial implementation of #244 - require explicit test.async
When using source maps to compute stack traces, if the source map is not in
memory, fall back to source-map-support's default retrieval function which can
get it from a source map pragma in the source file.
This means any dependency that has such pragmas (and the required map files) has
its errors mapped correctly, e.g. the code under test, or third-party
dependencies that ship with source maps.
This should also work for inline source maps, though no test case was included.
This adds basic source map support. Since transpilation of dependencies
is not merged yet, the `sourceMapCache` object and lookup is a little
premature (since we will only ever have one file that we can apply
apply source maps to).
log.errors() cycles through all the results from a file (passing and failing)
and prints out a summary of the failing tests and the assertion errors.
It was misidentfying all results as errors, and then throwing
when result.error turned out to be an empty object ({}).
I think the result object can be improved such that
result.error === false when there were no errors.
But that is for another PR.
Killing the parent process skips execution of `end` listeners
on remaining forked child processes.
This interferes with `nyc` if processes are kept running after
test completion.
Refrence: https://github.com/bcoe/nyc/issues/52
I realize this isn't very me like, but it will enable us to iterate faster and customize them for AVA's needs. We can consider moving it out again post-1.0.0. Also, a tiny assertion lib isn't very useful standalone anyways. If people are to use something that doesn't come with the testing framework they usually want something more powerful like Chai.