Description
I was having problems with some warnings being output to the console after the test had already passed, which was causing a lot of confusion. Sometimes I was also having issues—see vuejs/vue#7140—with my actual tests not reporting the error in the correct way, instead the error being logged to the console and then the test timing out later.
I've ended up rewriting all of my tests, including the synchronous ones, to basically look like this:
it('is something', (done) => {
Vue.config.errorHandler = done;
// do test
localVue.nextTick(done);
});(plus logic to make sure that Vue.config.errorHandler was set back to what it was supposed to be in before and afterEach)
There seem to be a lot of errors that are logged to the console in the next tick—for example, if you're using <router-link> and have VueRouter installed but haven't actually passed in a router—and these were causing a lot of issues in my tests because they were just being logged to the console.
Until I figured out that I had to do this let my test run for another tick and set up Vue.config.errorHandler, writing tests was really tricky! I was getting errors in the console, but they weren't failing the tests, and sometimes they were actually being output several tests later.
The stack trace also looked like this, but this might be a setup issue on my behalf:
ERROR LOG: TypeError{stack: 'render@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:51854:21
_render@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:10218:26
updateComponent@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8532:28
get@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8875:29
Watcher@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8864:15
mountComponent@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8536:28
$mount@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:13596:24
init@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:9811:19
createComponent@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:11263:10
createElm@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:11211:24
patch@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:11728:16
_update@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8404:28
updateComponent@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8532:17
get@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8875:29
Watcher@http://localhost:9876/base/index.js?b4bc4f750f67930cd8fde8390c76caa6f9a4df51:8864:15
...more lines...
Passing the errors to mocha resulted in a proper stack trace with line numbers and stuff.
Is this something anyone else has faced? Is there an easier way to deal with it?