Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to Test Method parameters from TestCleanup. #385

Closed
jchesshir opened this issue Mar 23, 2018 · 4 comments · Fixed by #4015
Closed

Access to Test Method parameters from TestCleanup. #385

jchesshir opened this issue Mar 23, 2018 · 4 comments · Fixed by #4015

Comments

@jchesshir
Copy link

jchesshir commented Mar 23, 2018

Description

I have test method hooked up to a data source attribute that is passing to a parameter an object that needs to be disposed at the end of the test. Consequently, I would like to have another function in the ITestDataSource interface that gives me back the object array that was just passed to the test function so that I can handle any objects in it that need to be disposed of.

Steps to reproduce

Here is a rough example.
This is an overridden data source attribute creating the object for the test, and using the object type in its display name:

public class ComplexTestAttribute : Attribute, ITestDataSource
{
    public IEnumerable<object[]> GetData(MethodInfo methodInfo)
    {
        for(int i = 0; i < 3; i++)
            yield return new object[1] { new ComplexObject(i) };
        }
    }

    public string GetDisplayName(MethodInfo methodInfo, object[] data)
    {
        if (data != null)
        {
            return string.Format(CultureInfo.CurrentCulture, "{0} ({1})", methodInfo.Name, data[0].GetType().Name);
        }
        return string.Format(CultureInfo.CurrentCulture, "{0} ({1})", methodInfo.Name, "Unknown driver");
    }

    //Theoretical cleanup function.
    public void TestCleanup(object[] data, TestContext testContext)
    {
        ComplexObject obj =  (ComplexObject)data[0];
        if(testContext.CurrentTestOutcome == UnitTestOutcome.Failed)
        {
            obj.HandleError();
        }
        obj.Dispose();
    }
}

And here is the test class that uses it:

[TestClass]
class myClass 
{
    [ComplexTest]
    [TestMethod]
    void myTest(ComplexObject obj) 
    {
        obj.RunTest();
    }
}

Expected behavior

It would be good to have a TestCleanup function in the ITestDataSource interface that takes the latest test record data AND the test context of the test. This way any cleanup or other follow up logic could happen within the test thread.

Actual behavior

Right now, I have the ITestDataSource class as a subclass of my test class, so that it can call a function with access to the TestContext object. However, since I have no access to the actual TestContext, or even to the test class instance that ran the object, I have to make my underlying TestContext object static, which is clearly not thread safe, and thus not conducive to parallelization.

Environment

Using Windows 10,
MSTest.TestFramework: version 1.2.0

@jchesshir jchesshir reopened this Mar 23, 2018
@jchesshir
Copy link
Author

Thought I had the wrong project for a minute there.

@jchesshir
Copy link
Author

Here's an idea. Perhaps some sort of CleanupData function added to the ITestDataSource interface would be good. It could return void and have merely the same object[] parameter that is given to the GetDisplayName function, which should be guaranteed to contain the same object array that was passed to the test method using the data source attribute.

@jchesshir
Copy link
Author

Last night I figured out a way to access the specific object after the test, although it is clearly a hack. Through setting breakpoints, I found that the GetDisplayName function gets run after the test does. Since it is given access to the object that just ran, I can use it to dispose of the object. I would be good to have a function specifically dedicated to this type of use, though.

@jchesshir
Copy link
Author

I have updated the request to reflect my new idea, plus added the idea of a special TestContext parameter to give more versatility within the test case's thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants