This prevents interference between the mini logger and child processes that use `console.log`. The mini reporter previously used logUpdate which deletes lines previously written with the logUpdate API before writing a new one. This caused problems if lines from console.log were written inbetween logUpdate calls. It would delete the users log messages instead of the test status line. To fix this, we store the last written last log line, clear it, write the users log output, then restore the last log line. This keeps the miniReporter output always at the bottom of the log output.
It also fixes an incorrect use of the `child_process` API. We were using the `stdio` option for `child_process.fork`, but that option is ignored (it is honored for just about every other method in that API). See: 7b355c5bb3/lib/child_process.js (L49-L50)
It also adds a set of visual tests which can be run via `npm run visual`. They must be run manually, and should be run as part of our pre-release process.
This fixes that regression, and extends the promise returning behavior to all assertions.
This would be useful in `async` test functions to bail on the remaining tests if some precondition fails. Simply `await` the assertion.
Instead depend on npm to dedupe. This is better as we will no longer fail if the user has Babel 6 and we Babel 5, and npm just won't dedupe. Same situation in the future when we're on Babel 6, but the user is still on Babel 5.
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.
There are two possible errors that can result in no test data being
received.
1. The user never imports `ava` in their test file.
2. The user has not written any tests in the file yet.
We treat both as errors, but were handling them differently.
Most problematic, one caused the promise to resolve, the other
caused the promise to reject.
I want to start focusing on getting our require times down,
both in the main thread and forked tests.
This adds `time-require` support directly to the CLI to assist in that.
This is especially important for forked test processes, where I currently
have to manually add a line of code each time I want to test an optimization.
I don't think this should be a publicly documented move. I think we want
the freedom to remove this once we are happy with performance.
I have placed comments above all `time-require` references, indicating
it is for internal use only. Users have been given fair warning against
relying on its inclusion long term.
Usage:
```sh
$ DEBUG=ava ./cli.js test/fixture/es2015.js --sorted
```
`--sorted` is optional. It sorts the requires from most expensive to least. The default is sequential sorting.
The output will display multiple `time-require` reports.
One for each forked process, and the last one for the main thread.
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
This passes terminal width information to, and enables ansi-color
support in, the forked process. It makes the output of `time-require`
much prettier when used in a fork.