英文:
Why does a test method with DataTestMethod decorator fail to run more than once when multiple DataRows with array arguments are specified?
问题
I discovered surprising behaviour of the DataTestMethod
and DataRow
attributes. I have implemented the following test; of course the overall context is more complex, but this is a minimal example.
[TestClass]
public class SomeTest
{
[DataRow(new int[] { 1, 2 })]
[DataRow(new int[] { 3, 4 })]
[DataRow(new int[] { 3, 5 })]
[DataRow(new int[] { 3, 6 })]
[DataTestMethod]
public void ErrorStuff(int[] array)
{
Assert.IsNotNull(array);
}
}
I was expecting that during test execution, ErrorStuff
is executed four times (namely for every DataRow
provided). However, this is not the case, it is executed once (for the first DataRow
, which I inspected by debugging the test).
It goes without saying that the test is not meaningful at all and there are other ways to test the desired behaviour. However, I wonder how this behaviour can be explained. As presented, it it just a toy example; however, this potentially means that some test cases are never executed and there is hardly any way to notice this.
Any ideas how the behaviour can be explained? Any help is appreciated!
However, please don't suggest technically different alternatives like usage of DynamicData
or formulation of single test methods for the single test cases - I am aware of that, but that is not my point of interest here.
英文:
I discovered surprising behaviour of the DataTestMethod
and DataRow
attributes. I have implemented the following test; of course the overall context is more complex, but this is a minimal example.
[TestClass]
public class SomeTest
{
[DataRow(new int[] { 1, 2 })]
[DataRow(new int[] { 3, 4 })]
[DataRow(new int[] { 3, 5 })]
[DataRow(new int[] { 3, 6 })]
[DataTestMethod]
public void ErrorStuff(int[] array)
{
Assert.IsNotNull(array);
}
}
I was expecting that during test execution, ErrorStuff
is executed four times (namely for every DataRow
provided). However, this is not the case, it is executed once (for the first DataRow
, which I inspected by debugging the test).
It goes without saying that the test is not meaningful at all and there are other ways to test the desired behaviour. However, I wonder how this behaviour can be explained. As presented, it it just a toy example; however, this potentially means that some test cases are never executed and there is hardly any way to notice this.
Any ideas how the behaviour can be explained? Any help is appreciated!
However, please don't suggest technically different alternatives like usage of DynamicData
or formulation of single test methods for the single test cases - I am aware of that, but that is not my point of interest here.
答案1
得分: 1
升级你的 MS 测试框架至 3.0+ 版本。
你可以通过 nuget 进行升级。写作时,当前版本是 3.0.4:
dotnet add package MSTest.TestFramework --version 3.0.4
升级框架后,这将按预期工作(会发生 4 次测试运行):
你 可能 也需要更改你的 .csproj 文件以匹配包的版本号:
<ItemGroup>
<PackageReference Include="MSTest.TestAdapter" Version="3.0.4" />
<PackageReference Include="MSTest.TestFramework" Version="3.0.4" />
</ItemGroup>
这似乎是一个 已知问题,并且根据该帖子的说法,似乎在 MSTest V3 发布时已经修复。链接的 GitHub 问题也详细说明了此 bug:
为了给你更多上下文和解释你在 VS 和命令行中看到的区别。基本上,VS 要求 MSTest 发现测试,然后我们返回一个列表,VS 使用每个测试 ID 作为运行/调试的唯一标识符。在 MSTest 2.2.3+ 版本中我们有一个 bug,在某些情况下,为带参数的测试中的 IDs 出现问题。这导致 VS 混合测试并且表现得像所有测试都具有第一个测试的数据。
注意,如果你通过持续集成(例如 Azure DevOps)运行此测试,似乎可以工作。该帖子还解释了为什么在这种情况下可以工作:
至于 CI,它使用了一种不同的机制,它不是要求发现然后重用信息来运行测试,而是直接运行测试,因此你在 CI 上不会遇到这个问题。
英文:
Upgrade your MS Test Framework to Version 3.0+.
You can do so via nuget. At the time of writing, the current is 3.0.4:
dotnet add package MSTest.TestFramework --version 3.0.4
After I upgraded my framework, this works as expected (4 test runs occur):
You may also need to change your .csproj file to match the version number of the package:
<ItemGroup>
<PackageReference Include="MSTest.TestAdapter" Version="3.0.4" />
<PackageReference Include="MSTest.TestFramework" Version="3.0.4" />
</ItemGroup>
This seems to of been a known issue, and appears to have been fixed with the release of MSTest V3 according to the post. The linked GitHub issue also goes into details of the bug:
> To give you a little more context and explain you the difference between what you see in VS and in command line. Basically, VS asks MSTest to discover tests, we then return a list and VS is using each test ID as a unique identifier for run/debug. We have a bug in 2.2.3+ of MSTest where IDs are broken for parameterized tests under some circumstances. This leads to VS mixing tests and behaving like all tests have the data of the 1st test.
Note that is seems like if you run this through a Continuous-Integration (such as Azure DevOps), it worked. The post also explains why it worked in that case:
> As for the CI, it is using a different mechanism where it's not asking for discovery then reuse information to run tests but directly runs tests hence you don't have the issue on CI.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论