Added ability for test cases to return Futures.

pkg/unittest/lib/unittest.dart

Index: pkg/unittest/lib/unittest.dart
===================================================================
--- pkg/unittest/lib/unittest.dart	(revision 18992)
+++ pkg/unittest/lib/unittest.dart	(working copy)
@@ -113,6 +113,18 @@
  * callback should be protected within a call to guardAsync(); this will ensure
  * that exceptions are properly handled.
  *
+ * A variation on this is expectAsyncUntilX(); this takes a callback as the first

[Siggi Cherem (dart-lang), 2013/02/26 00:25:29]

80 col

[gram, 2013/03/04 19:51:52]

Done.

+ * parameter and a predicate function as the second parameter; after each time 
+ * the callback is called, the predicate function will be called; if it returns 
+ * false the test will still be considered incomplete.
+ *
+ * Test functions can return [Future]s, which provide another way of doing
+ * asynchronous tests. The test framework will handle exceptions thrown by
+ * the Future, and will advance to the next test when the Future is complete. 
+ * It is still important to use expectAsync/guardAsync with any parts of the
+ * test that may be invoked via an [Isolate] (for example, with Timer.run()],

[Siggi Cherem (dart-lang), 2013/02/26 00:25:29]

rephrase: 'via an [Isolate]' sounds strange.

In the browser for example Timer.run uses window.setTimout. You also have
futures for XHR requests. 

How about  'may be in voked from a top-level context'?

[gram, 2013/03/04 19:51:52]

Done.

+ * as the Future exception handler will not capture exceptions in such code.
+ *
  * Note: due to some language limitations we have to use different functions
  * depending on the number of positional arguments of the callback. In the
  * future, we plan to expose a single `expectAsync` function that can be used
@@ -678,17 +690,17 @@
   }
 }
 
-/** Runs [callback] at the end of the event loop. */
+/**
+ * Runs [callback] at the end of the event loop. Note that we don't wrap
+ * the callback in guardAsync; this is for test framework functions which
+ * should not be throwing unexpected exceptions that end up failing test
+ * cases! Furthermore, we need the final exception to be thrown but not
+ * caught by the test framework if any test cases failed. However, tests
+ * that make use of a similar defer function *should* wrap the callback
+ * (as we do in unitttest_test.dart).
+ */
 _defer(void callback()) {
-  // Exploit isolate ports as a platform-independent mechanism to queue a
-  // message at the end of the event loop.
-  // TODO(sigmund): expose this functionality somewhere in our libraries.
-  final port = new ReceivePort();
-  port.receive((msg, reply) {
-    callback();
-    port.close();
-  });
-  port.toSendPort().send(null, null);
+  (new Future.immediate(null)).then((_) => callback());

[Siggi Cherem (dart-lang), 2013/02/26 00:25:29]

I wonder if anything depends on the old behavior here.

In dart2js this will do a setTimeout(0) -- (which I hope gets fixed soon), but
that will be at the beginning of the next eventloop. The old logic with ports
was guaranteed to be at the end of the same event-loop. 

[gram, 2013/03/04 19:51:52]

I've run all tests in vm (checked/unchecked) and all unchecked in dart2js/d8 and
dart2js/drt, plus quite a few in dart2js/drt checked, with no issues.

 }
 
 rerunTests() {
@@ -781,11 +793,7 @@
     final testCase = _tests[_currentTest];
     var f = guardAsync(testCase.run, null, _currentTest);
     if (f != null) {
-      f.then((_){})
-       .catchError((e) {
-        testCase.error(e.toString(), e.stackTrace);
-      })
-      .whenComplete(() {
+      f.whenComplete(() {
         _nextTestCase(); // Schedule the next test.
       });
       break;