First pass at build dependency graph for barback.

pkg/barback/test/asset_graph/errors_test.dart

+// Copyright (c) 2013, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+library barback.test.asset_graph.source_test;
+
+import 'dart:async';
+
+import 'package:barback/barback.dart';
+import 'package:barback/src/asset_graph.dart';
+import 'package:scheduled_test/scheduled_test.dart';
+
+import '../utils.dart';
+
+main() {
+  initConfig();
+
+  test("errors if two transformers output the same file", () {
+    var provider = new MockProvider({"app|foo.a": "foo"});
+    var graph = new AssetGraph(provider, [
+      [
+        new RewriteTransformer("a", "b"),
+        new RewriteTransformer("a", "b")
+      ]
+    ]);
+    graph.updateSources([new AssetId.parse("app|foo.a")]);
+
+    expectCollision(graph, "app|foo.b");

[nweiz, 2013/06/18 23:14:46]

I really think expect(graph, hasCollision("app|foo.b")) would read a lot better
here.

[Bob Nystrom, 2013/06/20 00:23:59]

My plan is to have utils.dart keep track of the graph directly. (It needs to do
that to register the build result listener early enough to ensure results aren't
dropped). That means you won't have to keep passing it in. At that point, I
think dedicated expectation functions are nice.

+  });
+
+  test("reports asset not found errors in results", () {
+    var provider = new MockProvider([]);
+    var graph = new AssetGraph(provider, []);
+
+    var gotError = false;
+    graph.results.listen(wrapAsync((result) {
+      expect(result.error is AssetNotFoundException, isTrue);

[nweiz, 2013/06/18 23:14:46]

expect(result.error, new isInstanceOf<AssetNotFoundException>())

[Bob Nystrom, 2013/06/20 00:23:59]

Done.

+      expect(result.error.id, equals(new AssetId.parse("app|foo.txt")));
+      gotError = true;
+    }));

[nweiz, 2013/06/18 23:14:46]

This wrapAsync/gotError stuff is complicated and gross. Why not do this:

    expect(schedule(() => graph.results.single).then((result) {
      expect(...);
    }), completes);

?

[Bob Nystrom, 2013/06/20 00:23:59]

Added a TODO. I'm planning to refactor it completely after this lands.

+
+    expectNoAsset(graph, "app|foo.txt");
+
+    schedule(() {
+      expect(gotError, isTrue);
+    });
+  });
+
+  test("reports missing input errors in results", () {
+    var provider = new MockProvider({"app|a.txt": "a.inc"});
+
+    var graph = new AssetGraph(provider, [
+      [new ManyToOneTransformer("txt")]
+    ]);
+
+    var gotError = false;
+    graph.results.listen(wrapAsync((result) {
+      expect(result.error is MissingInputException, isTrue);
+      expect(result.error.id, equals(new AssetId.parse("app|a.inc")));
+      gotError = true;
+    }));
+
+    graph.updateSources([new AssetId.parse("app|a.txt")]);
+
+    expectNoAsset(graph, "app|a.out");
+
+    schedule(() {
+      expect(gotError, isTrue);
+    });
+  });
+
+  test("fails if a non-primary input is removed", () {
+    var provider = new MockProvider({
+      "app|a.txt": "a.inc,b.inc,c.inc",
+      "app|a.inc": "a",
+      "app|b.inc": "b",
+      "app|c.inc": "c"
+    });
+
+    var graph = new AssetGraph(provider, [
+      [new ManyToOneTransformer("txt")]
+    ]);
+
+    var gotError = false;
+    graph.results.listen(wrapAsync((result) {
+      expect(result.error is MissingInputException, isTrue);
+      expect(result.error.id, equals(new AssetId.parse("app|b.inc")));
+      gotError = true;
+    }));

[nweiz, 2013/06/18 23:14:46]

It's confusing that you're setting this up before the call that *isn't* expected
to have an error, rather than before the one that *is*.

[Bob Nystrom, 2013/06/20 00:23:59]

This is a broadcast stream and the build process runs in the background. That
means as soon as you call updateSources(), it can start generating results. I
you don't start listening early, it will drop them on the floor.

This will get less nasty when I have a chance to refactor it.

+
+    graph.updateSources([
+      new AssetId.parse("app|a.txt"),
+      new AssetId.parse("app|a.inc"),
+      new AssetId.parse("app|b.inc"),
+      new AssetId.parse("app|c.inc")
+    ]);
+
+    expectAsset(graph, "app|a.out", "abc");
+
+    schedule(() {
+      graph.removeSources([new AssetId.parse("app|b.inc")]);
+    });
+
+    expectNoAsset(graph, "app|a.out");
+
+    schedule(() {
+      expect(gotError, isTrue);
+    });
+  });
+
+  test("catches transformer exceptions and reports them", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [
+      [new BadTransformer(["app|foo.out"])]
+    ]);
+
+    var gotError = false;
+    graph.results.listen(wrapAsync((result) {
+      expect(result.error, equals(BadTransformer.ERROR));
+      gotError = true;
+    }));
+
+    schedule(() {
+      graph.updateSources([new AssetId.parse("app|foo.txt")]);
+    });
+
+    expectNoAsset(graph, "app|foo.out");
+
+    schedule(() {
+      expect(gotError, isTrue);
+    });
+  });
+
+  // TODO(rnystrom): Is this the behavior we expect? If a transformer fails
+  // to transform a file, should we just skip past it to the source?

[nweiz, 2013/06/18 23:14:46]

Definitely not. If a transformer fails, getting the failed output asset should
expose that failure.

In general, once a preprocessor-phase transformer has been run on an asset, that
asset should no longer be available.

[Bob Nystrom, 2013/06/20 00:23:59]

I'm going to leave this test for now just to pin down the current behavior, but
I agree one thing I'll be working on soon is a coherent failure handling
strategy. I expect this test to change then.

+  test("yields a source if a transform fails on it", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [
+      [new BadTransformer(["app|foo.txt"])]
+    ]);
+
+    schedule(() {
+      graph.updateSources([new AssetId.parse("app|foo.txt")]);
+    });
+
+    expectAsset(graph, "app|foo.txt");
+  });
+
+  test("catches errors even if nothing is waiting for process results", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [[new BadTransformer([])]]);
+    var resultFuture = graph.results.first;

[nweiz, 2013/06/18 23:14:46]

Why are you getting this future here? Why not do it in schedule()?

[Bob Nystrom, 2013/06/20 00:23:59]

I need to make sure I grab it before the updateSources() call so the results
don't get discarded.

+
+    schedule(() {
+      graph.updateSources([new AssetId.parse("app|foo.txt")]);
+    });
+
+    // Note: No asset requests here.
+
+    schedule(() {
+      return resultFuture.then((result) {
+        expect(result.error, equals(BadTransformer.ERROR));
+      });
+    });

[nweiz, 2013/06/18 23:14:46]

I think wrapping the first argument to [expect] in [schedule] and using
[completion] is a little cleaner than wrapping an entire [then] call in
[schedule].

[Bob Nystrom, 2013/06/20 00:23:59]

Maybe it's just me, but I really prefer the schedule() calls to be at the top
level of the method. I think of them as imperative statements and not embeddable
expressions.

[nweiz, 2013/06/20 23:06:08]

I disagree. I like them best when they're inside library methods, but failing
that I'd rather it look like an inline library method than a series of
large-looking blocks. Using expect(..., completion(...)) can also produce nicer
output and error detection in many cases.

I also really don't like having to remember to return the inner future.

[Bob Nystrom, 2013/06/21 00:13:20]

My plan for the next patch is to clean up the tests, so these will be moved into
library methods. I agree this is ugly.

+  });
+
+  test("discards outputs from failed transforms", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [
+      [new BadTransformer(["a.out", "b.out"])]
+    ]);
+
+    schedule(() {
+      graph.updateSources([new AssetId.parse("app|foo.txt")]);
+    });
+
+    expectNoAsset(graph, "app|a.out");
+  });
+}