Improve Source Generator Test Validation - Validate Generator Output

[michael-hawker]

I've fixed this issue locally and created a new analyzer with an improved error message, but I'm not able to write unit tests for that diagnostic error (yet).

This particular test requires you to apply a generator to an assembly, and check symbols in all referenced assemblies. Our unit tests here are, in their current form, lacking the flexibility required to pull this off.

I can do a small refactor and add the flexibility needed to accommodate this and future unit tests for our primary source generator (CommunityToolkit.Labs.Core.SourceGenerators), but it'll take a few more hours of work.

Originally posted by @Arlodotexe in #180 (comment)

As part of #189 I discovered there were cases for the [LabsUITestMethod] was not generating code, this was due to an extra line of filter code when searching for methods. This wasn't caught by our existing tests, as our SG tests are only looking for non-failure state of the roslyn compiler (which means it may not just be outputting code as well) OR a diagnostic failure during compile time.

We need to look at the actual generated output as well to ensure our correct behavior.

I've started doing this in #189 for the [LabsUITestMethod], albeit naively. Initially just checking that there was some output with driver.GetRunResult().GeneratedTrees.Length > 0.

The GeneratedTrees can contain the actual generated source text, as well as a walkable SyntaxTree. I added some basic text comparison on the source for now, but we should take time with this issue to shore this up to be a bit more robust to renaming things for re-use or refactoring. As well as apply this to our other source generator tests for samples/docs.

[Arlodotexe]

Thanks for filing this @michael-hawker.

There's a number of improvements that need to be made to our source generator tests, both functional and semantic. I'll list them out at a later date when I have a bit more time, or on request if this becomes a priority.