Added Area-Pkg, Pkg-Unittest labels.

This comment was originally written by @zoechi

You shouldn't need expectAsync here because you return a Future.
As far as I know it is better to use
    new Future.delayed(new Duration ...
instead of new Timer(
new Future.delayed respects zones and the error handling is better when the delayed function throws.
One disadvantage of Future.delayed is that it can not be cancelled.
None of this changes does fix your issue though.

This way would probably allow you to verify async execution similar to a completer

main() {
  test('foo', () {
    var done = expectAsync((){});
    new Future.delayed(new Duration(seconds: 1), () {
      expect(false, isTrue);
      done();
    });
  });
}

this worked too

main() {
  test('foo', () {
    var completer = new Completer();
    new Future.delayed(new Duration(seconds: 1), () {
      expect(false, isTrue);
      completer.complete();
    }).catchError((e) => completer.completeError(e));
    return completer.future;
  });
}

I don't understand how https://codereview.chromium.org/416563002/ will fix the problem.
Why not use try/finally block to complete the Completer?

main() {
  test('foo', () {
    var completer = new Completer();
    new Timer(new Duration(seconds: 1), expectAsync(() {
      try {
        expect(false, isTrue);
      } finally {
        completer.complete();
      }
    }));
    return completer.future;
  });
}

Just to clarify: I agree that the solutions suggested in comments 2 and 3 would fix my contrived example. Unfortunately they don't address the real-world situation where this bug came up (the analysis server integration tests). They reason they don't work for the analysis server integration tests is that in the real-world tests, instead of the asynchronous event happening in a timer, the asynchronous event is a particular kind of response we're expecting to receive from the analysis server subprocess. To make matters more difficult, the set of possible responses we might be waiting to receive from the subprocess varies from test to test; keeping track of the completers for all of these anticipated responses would be a lot of bookkeeping, and making sure to complete all of them in the event of every possible error would be easy to get wrong. It seemed like it would be better if the unittest framework could just abort the test if an error occurs during a callback (and as far as I can tell that seems to be the design intent of unittest--it simply doesn't work in the limited case where the test returns a future and that future has not yet completed).

The reason that https://codereview.chromium.org/416563002/ works around the problem is that it changes the test from one that returns a future to one that returns void (essentially it's the same workaround I described in the last two sentences of the bug report). This works because when the test returns void, the unit test framework (see unittest.TestCase._run()) immediately sets _testComplete to a new Completer and then starts waiting for all callbacks to complete (including the one that the workaround artificially introduced). If any callback experiences a failure while it's waiting, then _fail() will call _complete(), which will complete the completer and the test will abort. By contrast, without the workaround, _run() waits until the future returned by the test completes before setting _testComplete. As a result, if an asynchronous error happens during a callback that's unrelated to the future while _run() is waiting for the future returned by the test, there's no completer for _complete() to complete, so the test keeps running until it times out.

(Note: further discussion of https://codereview.chromium.org/416563002/ probably would be best to do over to the code review website)

Ok, now that I've investigated this further, I think I see how to fix it.

Added Started label.

Set owner to @stereotype441.

Fixed in revision 39013.

Added Fixed label.

This issue has been moved to dart-lang/test#256.