Jacob MacDonald

You can look at the [DevCompilerBuilder](https://github.com/dart-lang/build/blob/master/build_web_compilers/test/dev_compiler_builder_test.dart) unit test for an example. The key is the [testBuilderAndCollectAssets](https://github.com/dart-lang/build/blob/master/build_web_compilers/test/util.dart#L11) utility method which runs a builder using the normal `testBuilder` command and after it...

In terms of directly testing a `Resource` they should be testable independently... it is really just giving you a handle on a persistent object. The thing you are actually returning...

Ah, I see what you mean now. In order to test a more real world scenario where resources are shared between [testBuilder](https://pub.dev/documentation/build_test/latest/build_test/testBuilder.html) calls, or maybe even mock one, you would...

I like the idea of publishing the `DecodingCache`. I guess the main question is where, it could potentially just be added to the `build` package.

I guess it would probably make sense for it to work off of bytes only, and maybe accept an encoder/decoder or something.

Makes sense, we already have a `--output` flag but we could add a `--test-output` flag or similar (although that might be confusing as it would have a totally different meaning...

We have some other ideas coming down the line which would be relevant as well when it comes to tool integration, so we might want to hold off on a...

https://github.com/dart-lang/build/blob/master/build_test/lib/src/resolve_source.dart#L197 😢

Awaiting that fixes the issue but then the test has to be updated to expect the new exception type (which is the documented one, previously it threw a different one)....

Ya if we awaited there we would block on the `tearDown` future being resolved so this would just hang tests that use that. I don't really know what the correct...