Repository: avajs/ava

Issue #214: Use domains to track which test threw an error.
Created: 2015-11-14T04:28:48Z
The goal would be to track which test threw a given uncaughtException.
Domains have been "soft deprecated". Unfortunately, there is no clear alternative at this time.
See this discussion in the node repo.

The goal is to replace the functionality before fully removing it or recommending specific alternate approaches; this is an attempt to telegraph that any new code written against this feature will likely be subject to some churn in the near future, and that folks who can avoid that churn, should. My hope is that fewer folks directly depend on domain, and instead indirectly depending on the functionality though another package -- hapi, express, et al -- and that that would move the onus of updating domains-based code to fewer folks. Also, by not redirecting folks who need this functionality to other APIs, we cut down on both the number of times users have to change their code to a different API and the number of folks we "lose" by diverting their attention to a different API. It keeps the focus on domains and the eventual successor API, that is.
TL;DR: No specific suggestions yet (by design); just clearly labeling the footgun and mentioning that it's there if you need [it] to separate some feet from some legs, but soon there will be a better way to practice podiatry. If you'd like to take a stab at the wording in a separate PR I'd totally welcome it!

The gist is that the API is not going to disappear until a viable alternative exists.
The major arguments for deprecating domains is that people have tried to use them the wrong way (to prevent an http server from shutting down, etc). The danger with doing so in a production app is that the engine is left in an unknowable state that can be impossible to reliably recover from. Test frameworks face no such danger. When an uncaughtException is encountered, we are already marking the test as failed, and the process (by definition) will be bailing shortly anyways.
AVA is at a particular advantage here over other test frameworks since concurrent testing basically enforces zero shared state between tests. Looking at the domain API, it seems relatively straight forward, and anything we come up with should be fairly simple to whatever replacement comes along.
Given that the deprecation discussion took place nearly a year ago, and that the domain implementation is currently being actively contributed to - I think it's a good play. Especially if we stay mindful of the impending deprecation and work to minimize it's impact.

Duplicate issue #567: Asynchronous errors do not fail tests
Created: 2016-02-19T01:22:54Z
Hey all
Just wondering if this is expected output
var test = require('ava').test;

test.beforeEach(t => {
   console.log('before each');
});

test(t => {
     setTimeout(function(){
       throw new Error('123');
     });
});

test(t => {
     setImmediate(function(){
       throw new Error('456');
     });
});

test(t => {
     process.nextTick(function(){
       throw new Error('789');
     });
});
output:
  3 passed
  3 exceptions

  1. Uncaught Exception
  Error: 789


  2. Uncaught Exception
  Error: 456


  3. Uncaught Exception
  Error: 123

shouldn't it be 0 passed, 3 exceptions?

Closing comment (2016-09-21T15:48:53Z): #214 already discusses AVA's inability to trace uncaught exceptions back to their tests. I've opened #1045 to document the resulting pitfalls, with a suggestion to promisify callback-taking functions.
Closing this as a duplicate of #214.