`build_test` improvements following feedback

[davidmorgan]

See https://github.com/dart-lang/build/discussions/4036#discussioncomment-13486284

[davidmorgan]

@simolus3 Re: adding more information about what was read.

Reads are recorded in build_runner_core/lib/src/generate/input_tracker.dart then exposed to tests via build_test/lib/src/in_memory_reader_writer.dart.

Currently InputTracker does not know the primary input of its step, but that would be easy to do. Then in ReaderWriterTesting we could add e.g. inputsTrackedFor(AssetId primaryInput) next to inputsTracked.

However it would not distinguish multiple builders running on the same primary input.

Internally that would be the phase number, but that's not currently exposed anywhere or even logged.

We could split by primary input + builder label? Pretty much, what shows in the logs.

Note that build_runner no longer tracks the transitive dependencies of a resolved file as a set of AssetId, instead it tracks the entrypoints that are resolved and these link into a shared import graph. That graph is not exposed to tests today. So for example if you resolve a.dart and it imports b.dart there is currently no easy way to check b.dart in tests.

This is in ReaderWriterTesting as resolverEntrypointsTracked, which we could further split by primary input + builder label in the same way.

[simolus3]

We could split by primary input + builder label? Pretty much, what shows in the logs.

I think that would cover my use cases.

Note that build_runner no longer tracks the transitive dependencies of a resolved file as a set of AssetId, instead it tracks the entrypoints that are resolved and these link into a shared import graph

Oh nice! Yeah I'm not that familiar with the refactor yet :) But again I think splitting resolverEntrypointsTracked by input and builder label would be enough to assert that my builders aren't reading too much.