_From @marcind on September 1, 2016 21:4_
Member specified by the attribute must be
IEnumerable<object[]>MemberType specified, member must be available on test classxunit.core version 2.2.0 or later, in which case we'd want to verify concrete subclassesThis should probably be different rules, depending on implementation complexity
_Copied from original issue: xunit/xunit.analyzers#6_
I want to use the pattern of #967, but it seems it is pending this issue? Maybe #967 should be reopened because it is not possible to run the example.
I am running the example from #967 (XUnitTestProject.zip):
using System;
using System.Collections.Generic;
using Xunit;
namespace XUnitTestProject
{
public abstract class BaseClassWithTestWithoutData
{
[Theory]
[MemberData("TestData")]
public void Test(int data) { }
}
public class SubClassWithTestData : BaseClassWithTestWithoutData
{
public static IEnumerable<object[]> TestData()
{
yield return new object[] { 42 };
}
}
}
executed with dotnet xunit as explained in the documentation, I get the following:
$ dotnet xunit
Detecting target frameworks in XUnitTestProject.csproj...
Building for framework netcoreapp1.1...
UnitTest1.cs(10,10): error xUnit1015: MemberData must reference an existing member 'TestData' on type 'XUnitTestProject.BaseClassWithTestWithoutData'. [C:\Users\xxx\src\XUnitTestProject\XUnitTestProject\XUnitTestProject.csproj]
Build failed!
It also fails with the testrunner from VS2017.
Csproj-file looks like:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
<PackageReference Include="xunit" Version="2.3.0-beta3-build3705" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.0-beta3-build3705" />
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta3-build3705" />
</ItemGroup>
</Project>
You can disable the rule xUnit1015 until the problem gets fixed.
Hi all,
Would love to use this pattern also.
It would cut down boilerplate code in every sub class.
However, I am also unable to use this pattern..
Running xUnit 2.4.1 on a .NET Core 2.1 project - disabling xUnit1015 results in the following exception:
System.NotSupportedException : Specified method is not supported.
Not sure if the work around does not work because it's a newer version of .NET Core?
The abstract class also makes use of generics, so maybe that is the issue?
Most helpful comment
Hi all,
Would love to use this pattern also.
It would cut down boilerplate code in every sub class.
However, I am also unable to use this pattern..
Running
xUnit 2.4.1on a.NET Core 2.1project - disablingxUnit1015results in the following exception:System.NotSupportedException : Specified method is not supported.Not sure if the work around does not work because it's a newer version of .NET Core?
The abstract class also makes use of generics, so maybe that is the issue?