使用Nunit映射测试用例ID

Question

I'm currently building out my automation framework using Nunit, I've got everything working just fine and the last enchancement I'd like to make is to be able to map my automated test scripts to test cases in my testing software.

I'm using TestRail for all my testcases.

My ideal situation is to be able to decorate each test case with the corresponding testcase ID in test rail and when it comes to report the test result in TestRail, I can just use the Case id. Currently I'm doing this via matching test name/script name.

Example -

[Test]
[TestCaseId("001")]
    public void NavigateToSite()
    {
        LoginPage login = new LoginPage(Driver);
        login.NavigateToLogInPage();
        login.AssertLoginPageLoaded();
    }

And then in my teardown method, it would be something like -

[TearDown]
public static void TestTearDown(IWebDriver Driver)
    {
       var testcaseId = TestContext.CurrentContext.TestCaseid;
       var result = TestContext.CurrentContext.Result.Outcome;

      //Static method to report to Testrail using API
      Report.ReportTestResult(testcaseId, result);
    }

I've just made up the testcaseid attribute, but this is what I'm looking for.

[TestCaseId("001")]

I may have missed this if it already exists, or how do I go about possibly extending Nunit to do this?

Any help would be awesome.

Thanks.

Answer 1

You can use PropertyAttribute supplied by NUnit.

Example:

[Property("TestCaseId", "001")]
[Test]
public void NavigateToSite()
{
...
}

[TearDown]
public void TearDown()
{
    var testCaseId = TestContext.CurrentContext.Test.Properties["TestCaseId"];
}

In addition you can create custom property attribute - see NUnit link

Answer 2

For many years I recommended that people not do this: mix test management code into the tests themselves. It's an obvious violation of the single responsibility principle and it creates difficulties in maintaining the tests.

In addition, there's the problem that the result presented in TearDown may not be final . For example, if you have used [MaxTime] on the test and it exceeds the time specified, your successful test will change to a failure. Several other built-in attributes work this way and of course there is always the possibility of a user-created attribute. The purpose of TearDown is to clean up after your code, not as a springboard for creating a reporting or test management system.

That said, with older versions of NUnit, folks got into the habit of doing this. This was in part due to the fact that NUnit addins (the approach we designed) were fairly complicated to write. There were also fewer problems because NUNit V2 was significantly less extensible on the test side of things. With 3.0, we provided a means for creating test management functions such as this as extensions to the NUnit engine and I suggest you consider using that facility instead of mixing them in with the test code.

The general approach would be to create a property, as suggested in Sulo's answer but to replace your TearDown code with an EventListener extension that reports the result to TestRail. The EventListener has access all the result information - not just the limited fields available in TestContext - in XML format. You can readily extract whatever needs to go to TestRail.

Details of writing TestEngine extensions are found here: https://github.com/nunit/docs/wiki/Writing-Engine-Extensions

Note that are some outstanding issues if you want to use extensions under the Visual Studio adapter, which we are working on. Right now, you'll get the best experience using the console runner.