在测试中首先调用有关确保某种方法接受lambda的FxCop规则

Question

Using a custom FXCop rule, I want to ensure that a method is called at the top of each unit test and that all unit test code is part of an Action passed into that method. Essentially I want this:

    [TestMethod]
    public void SomeTest()
    {
        Run(() => {
            // ALL unit test code has to be inside a Run call
        });
    }

It's not hard to ensure that Run is indeed called:

public override void VisitMethod(Method member)
    {
        var method = member as Method;
        if (method == null || method.Attributes == null)
            return;

        if (method.Attributes.Any(attr => attr.Type.Name.Name == "TestMethodAttribute") &&
            method.Instructions != null)
        {
             if (!method.Instructions.Any(i => i.OpCode == OpCode.Call || i.Value.ToString() == "MyNamespace.Run"))
            {
                this.Problems.Add(new Problem(this.GetResolution(), method.GetUnmangledNameWithoutTypeParameters()));
            }

        base.VisitMethod(method);
    }

The trick is to ensure there isn't something at the top of the test that is called BEFORE the Run statement. I've spent the past few hours hacking at the Instructions collection for patterns and trying to understand how to use the Body.Statements collection in code effectively.

---

This could also be posed as a simple IL question. I want to know a specific pattern I can validate that will accept this:

public void SomeTest()
{
    Run(() => {
        // Potentially lots of code
    });
}

But will reject either of these:

public void SomeTest()
{
    String blah = “no code allowed before Run”;
    Run(() => {
        // Potentially lots of code
    });
}

public void SomeTest()
{
    Run(() => {
        // Potentially lots of code
    });
    String blah = “no code allowed after Run”;
}

Answer 1

Although you can access an expression tree like structure using Method.Body I would probably examine the instructions anyway as I have found it to get confused by common situations in the past (eg. inline array initialisation).

How C# generates the lambda expression depends on what the lambda expression accesses:

• If the lambda expression accesses any locals/parameters, it will create an object to hold those values where they can be accessed from the lambda expression, and then create a delegate to an instance method on the object.
• If the lambda expression accesses any instance members via this , then it will simply create the delegate to the instance method on this .
• Otherwise if the lambda expression doesn't access locals or fields:
  • Prior to the Roslyn compiler that came with VS2015, it would create a delegate to a static method and cache it in a static field.
  • As of the Roslyn compiler, it would create an instance method on a nested class and cache the delegate in a static method. (this change was made for performance reasons, calling a delegate to an instance method is faster than calling a delegate to a static method as it doesn't have to shuffle arguments across.)

You could probably create your own evaluation stack and trace the values through the method (I have had to do this in the past, non-trivial and a fair bit of code but not particularly difficult), but I suspect you could achieve "good enough" just by enforcing the following rules:

• All locals for the method must be compiler generated.
• Static fields may be accessed only if they are compiler generated.
• Only System.Action and compiler generated types may be created.
• Only Run may be called, and it must be called exactly once.
• The call to Run must be followed by a ret instruction (ignoring any number of nop instructions that may appear between them).
• No branch instruction may jump to a location after the call to Run .
• Prohibit all instructions other than the following:
  • branch instructions (conditional and unconditional)
  • argument, local and field accessor instructions.
  • newobj , call , callvirt , ldftn , nop , ret , ldnull
  • _Locals (this is just a pseudo instruction that FxCop inserts for local variables.)

FxCop provides RuleUtilities.IsCompilerGenerated to determine if a local is compiler generated, but it won't help for fields and I suspect only for locals if FxCop can find the pdb file. You might find it easier to say "the local/field/type is compiler generated if it's type name is not a valid identifier in C#".

---

Having said all that, insisting that all tests run entirely via the Run method seems a little arbitrary. If the goal is for the Run method to provide common setup/tear-down logic, there are better ways provided via nunit. Enforcing that people apply your action attribute is much easier than enforcing that they write their test in a particular way.

Alternatively, you could write a Roslyn analyzer instead; analyzers have access to the syntax tree describing how the code was written, without having to reverse engineer the structure from the IL & metadata.