Create a test help for writing simpler metadata tests

[davidwengier]

Thoughts @tmat?

I like that it puts the source code near the expected results, but I wonder if you preferred it the other way?

Mainly it just stops me from doing bad copy-and-pastes where I copy from diff1, and missing changing one of the things to reader2 or md2 and get weird test failures 😛

[tmat]

Good idea. I'd however try to avoid having a single method (AddGeneration) with gazillion parameters that needs to express everything we may want to test.

Instead, perhaps let it take a lambda that has access to the data and calls various Verify helpers on them.

[davidwengier]

Yeah, that could work, we'd just need AddGeneration to take the edits, and there could be a Verify method that takes a Action<GenerationInfo> that has the methods. Will have a play.

[davidwengier]

Updated with a lambda. I think I like it better, in particular its nice that I can now click the right thing on a stack trace in a test failure and be taken to the right verify call.

[tmat]

List _readers;

This is a bit odd - the class is immutable except for the list of readers. I think we should take a snapshot of the readers list.

[davidwengier]

Yeah, I knew this was lazy when I did it, I should have fixed it. This should be a field that holds a reference to the test, and the readers should be publically accessible from there. Sometimes I get lazy with test code. Will fix :)

[tmat]

So another thing - we should use the MetadataAggregator - see the helper that I added in my last PR.

[davidwengier]

Will have to talk to you about this tomorrow. I tried using the CheckNames method you added, but it gets a different answer in my test for the type defs in the 3rd generation ¯\_(ツ)_/¯

[davidwengier]

Anything left on this @tmat?

Can always follow up with more validations as needed of course.

[tmat]

VerifyMemberRefNames

As a follow up - we should be able to resolve fully qualified names of MemberRefs, MethodDefs and TypeDefs.

[tmat]