Testfx: mstest.exe doesn't support [DataRow()] attribute

[JVimes]

Description

If your tests use the [DataRow()] attribute, mstest.exe gives an error, citing wrong signature.

Steps to reproduce

1. Create a new Test project

2. Make the default test look like this:

   [TestMethod]
   [DataRow(1, 2)]
   public void TestMethod1(int input, int expected)
   {
   }
   

3. Build.

4. Run msbuild.exe on the test dll, from the command line. Something like this:

   & "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\MSTest.exe" /testcontainer:"C:\Users\username\Documents\Visual Studio 2017\Projects\UnitTestProject1\UnitTestProject1\bin\Debug\UnitTestProject1.dll"
   

Expected behavior

Unit tests run.

Actual behavior

It shows the following error error:

UTA007: Method TestMethod1 defined in class UnitTestProject1.UnitTest1 does not have correct signature. Test method marked with the [TestMethod] attribute must be non-static, public, does not return a value and should not take any parameter. for example: public void Test.Class1.Test().

Environment

Windows 10
Visual Studio 2017 Community 15.1 (26403.7)
MSTest.TestAdapter 1.1.17
MSTest.TestFramework 1.1.17

[AbhitejJohn]

@JVimes : mstest.exe(which is the legacy runner) does not support MSTest V2 based projects. It lacks that extensibility which is why xunit/nunit tests cannot be run with it as well. vstest.console.exe which is the default runner for all our workflows is the entry point for CLI scenarios.

[JVimes]

@AbhitejJohn Thanks. It's very, very difficult find accurate, up-to-date MSTest documentation via Google/Bing. The out-of-date MSDN pages come up, and later pages don't. I hope the team is working to remedy that situation. Users need something more like NUnit's wiki. MSDN is hard to navigate and read.

[AbhitejJohn]

@JVimes : That's true. We are working to get that up soon. Here is most likely where this would show up.

[JVimes]

Another idea is to put a deprecation warning in MSTest.exe's startup text, referencing vstest.console.exe.

[AbhitejJohn]

Yes, that's likely what we would do. Users would see this message right there and shift.