First pass at build dependency graph for barback.

pkg/barback/test/asset_graph/source_test.dart

Index: pkg/barback/test/asset_graph/source_test.dart
diff --git a/pkg/barback/test/asset_graph/source_test.dart b/pkg/barback/test/asset_graph/source_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..86daf1f2fc9bf4a12df0ebd0e1248ee45c7d49d1
--- /dev/null
+++ b/pkg/barback/test/asset_graph/source_test.dart
@@ -0,0 +1,109 @@
+// 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:scheduled_test/scheduled_test.dart';
+

[nweiz, 2013/06/14 00:57:57]

Unnecessary blank line.

[Bob Nystrom, 2013/06/17 23:35:05]

Done.

+import 'package:barback/barback.dart';
+import 'package:barback/src/asset_graph.dart';
+
+import '../utils.dart';
+
+main() {
+  initConfig();
+  test("gets a source asset", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, []);
+    graph.updateSources([AssetId.parse("app|foo.txt")]);
+
+    expectAsset(graph, "app|foo.txt");

[nweiz, 2013/06/14 00:57:57]

"expectAsset" is a confusing name. I have to look in utils to figure out what it
means. "expectAssetExists" would be better, although perhaps "expect(graph,
producesAsset(...))" would be best.

[Bob Nystrom, 2013/06/17 23:35:05]

"exists" is a bit confusing to me because that feels like a weird fit for
generated assets.
That would read OK, but it's using scheduled_test internally, so that would be a
weird fit. expectAsset() gets used pretty frequently, so I thought something
terse would be good.

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

I don't think it's particularly weird to have a matcher that uses
scheduled_test. The [completes] and [completion] matchers already do.

It's certainly not any clearer that `expectAsset(graph, ...)` uses
scheduled_test than `expect(graph, customMatcher(...))`.

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

I've got some other test refactoring I want to do after this goes in (to
minimize churn on what you have to re-review). I'm up for improving this then.

+  });
+
+  test("doesn't get an unknown source", () {

[nweiz, 2013/06/14 00:57:57]

The term "source" is confusing. I think of packages as the sources of assets. A
"source asset" isn't really the source of anything. I get the association with
"source code", I guess, but I'd rather find a different name. "Concrete asset"?
"Initial asset"? "Un-transformed asset"?

[Bob Nystrom, 2013/06/17 23:35:05]

I'm not crazy about it either. Maybe "raw" input? I'm definitely up for changing
the name to something better, but if it's OK I'd put that in another patch.

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

Sure, another patch is fine.

+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, []);
+
+    expectNoAsset(graph, "app|unknown.txt");
+  });
+
+  test("doesn't get an asset that isn't an updated source", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, []);
+
+    expectNoAsset(graph, "app|foo.txt");

[nweiz, 2013/06/14 00:57:57]

Wait, why will this not exist? It's right there!

[Bob Nystrom, 2013/06/17 23:35:05]

You have to specifically tell barback "this file exists" (or "was updated"). If
you just request an asset, it won't go straight to the provider to see if it's
there.

We could support that, but I kind of like the idea of users explicitly saying
"here's the set of inputs to work with". It also makes it clearer when
transforms are wired up and to which files. If we just start wiring up
transforms to every single file you can possibly reach from the provider, it
will probably end up doing weird things (like re-processing stuff in output
directories).

Making this explicit lets the provider be simpler.

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

So how does the user specify this? If I run "pub deploy", how do I tell barback
which files I want to be compiled?

In any case, add a comment explaining what's going on here.

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

Pub deploy will automatically call updateSources() on everything that's in your
web directory. (But note that it's *provider* will let you access stuff in web,
lib, etc.)

If you're implementing a push-based build step using barback, that's the basic
model:

1. update all of the source inputs in one lump
2. wait for the build to complete
3. gather all of the output assets and write them to disk

(Of course, all of those still need more fleshing out right now, but I'm working
on it.)

Added a comment.

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

It seems a little weird that the set of available sources comes from the
provider, but the set of sources that actually (might) need compiling comes from
whoever's calling barback.

Do you have a test for what happens if [updateSources] is called with an id that
the provider doesn't provide?

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

The code calling barback also is responsible for giving it a provider, so I
think this ends up working out.
I do now. It behaves like a missing input for a transformer.

+  });
+
+  test("gets a source asset if not transformed", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [
+      [new RewriteTransformer("nottxt", "whatever")]
+    ]);
+    graph.updateSources([AssetId.parse("app|foo.txt")]);
+
+    expectAsset(graph, "app|foo.txt");
+  });
+
+  test("doesn't get a removed source", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [[]]);
+
+    schedule(() {
+      graph.updateSources([AssetId.parse("app|foo.txt")]);

[nweiz, 2013/06/14 00:57:57]

Why is this [updateSources] scheduled, but the previous one is not?

[Bob Nystrom, 2013/06/17 23:35:05]

No reason. Removed.

+    });
+
+    expectAsset(graph, "app|foo.txt");
+
+    schedule(() {
+      graph.removeSources([AssetId.parse("app|foo.txt")]);
+    });
+
+    expectNoAsset(graph, "app|foo.txt");
+  });
+
+  test("collapses redundant updates", () {
+    var provider = new MockProvider({"app|foo.blub": "foo"});
+    var transformer = new RewriteTransformer("blub", "blab");
+    var graph = new AssetGraph(provider, [[transformer]]);
+
+    schedule(() {
+      // Make a bunch of synchronous update calls.
+      graph.updateSources([AssetId.parse("app|foo.blub")]);
+      graph.updateSources([AssetId.parse("app|foo.blub")]);
+      graph.updateSources([AssetId.parse("app|foo.blub")]);
+      graph.updateSources([AssetId.parse("app|foo.blub")]);
+    });
+
+    expectAsset(graph, "app|foo.blab", "foo.blab");
+
+    schedule(() {
+      expect(transformer.numRuns, equals(1));
+    });
+  });
+
+  test("a removal cancels out an update", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [[]]);
+
+    schedule(() {
+      graph.updateSources([AssetId.parse("app|foo.txt")]);
+      graph.removeSources([AssetId.parse("app|foo.txt")]);
+    });
+
+    expectNoAsset(graph, "app|foo.txt");
+  });
+
+  test("an update cancels out a removal", () {
+    var provider = new MockProvider(["app|foo.txt"]);
+    var graph = new AssetGraph(provider, [[]]);
+
+    schedule(() {
+      graph.removeSources([AssetId.parse("app|foo.txt")]);
+      graph.updateSources([AssetId.parse("app|foo.txt")]);
+    });
+
+    expectAsset(graph, "app|foo.txt");
+  });
+}

[nweiz, 2013/06/14 00:57:57]

If this is where you're testing add/remove/update behavior, there need to be a
lot more tests here of situations where the changes happen before, after, and
during the processing of transformation.

[Bob Nystrom, 2013/06/17 23:35:05]

There are some tests for this. Added a couple more. I'm sure there are more
cases I can cover, but it's hard to know which ones I should do.