Use the Test 'Name' attribute to display the human readable name of the scenario in the test explorer

[binarysenator]

Both XUnit and MSTest support the ability to provide an additional Name parameter in the test attribute e.g. [Test("My wonderful test")] it would be great if reqnroll could support this additional attribute in these cases so that in the test explorer the display name isn't the Method name. So MyWonderfulTest would appear instead as "My wonderful test". The test name would use the scenario short name in this example.

[gasparnagy]

For XUnit we do this already and I always see the human readable title both in the test explorer and also in the dotnet test runner.

For MsTest, this would be nice, but not that easy. The syntax we should generate is [TestMethod("this is the nice title")] or [TestMethod(DisplayName = "this is the nice title")]). It seems that it works with all versions of MSTest.TestFramework that we support (v2.2.8 or above).

However, this only works for normal tests (so normal scenarios in our case), with tests using [DataRow] (so scenario outlines), this attribute seems to be ignored. So you still see the method name. What you can do is to generate a DisplayName property for the [DataRow] attribute in that case and include the scenario name and the parameters, like [DataRow("foo", 42, DisplayName = "this is my scenario(foo,42)")]. But of course this is also doable.

If someone is interested to send a PR for this, that would be awesome.

[Code-Grump]

Should we include table headings in the description for scenario outlines?

this is my scenario(Name: foo, Count: 42)

Are there any standard or existing formats we should emulate?

[gasparnagy]

There are some tools that need to match the test result (from the name) to the example row in the examples table, so we have to provide this information in a "reverse engineerable" way. (My tool SpecSync also does that.) There is no standard notion however:

Given the method was defined as public void MyMethod(string strParam, int intParam)

• MsTest used a comma separated list of parameters in parenthesis, without quotes around string (no space after comma): MyMethod(foo,42)
• xUnit used a parameter-annotated name, also in parenthesis (space after comma): MyMethod(strParam: "bar", intParam: 43)
• NUnit also used comma separated list, but with quotes around strings (no space after comma): MyMethod("foo",42)

Of course all had also different solutions for escaping the relevant characters, like quote ("), comma (,) or closing parenthesis ()). Also some of them strips the long text param values and substitutes with an ellipses, like This is a very long value and .... So quite some magic. 😊This need to be researched more accurately and follow the selected one.

For the first look, the xUnit seems to be the coolest, but in practice, it generates very long names, so you need to scroll right in order to see the relevant values. So it is not the ultimate best.

The tools that parse the results probably need to be modified even if we stick to the MsTest notation (breaking change?), but still, I would try to stick to one of these and not invent a new one. I would say we should decide if we stick to the MsTest one or use the xUnit style. I don't have a strong opinion and fine with any of these, but maybe my vote would be to stick to MsTest style.