I am working on some test cases that may be better designed using generics. I am trying to use TestCaseSource
with many different combinations of types.
The problem that I am encountering is the use of reflection in my tests to invoke a generic test method that I use for object validation.
[TestFixture]
public class SomeTests
{
public static IEnumerable<TestCaseData> TestCases()
{
yield return
new TestCaseData(
typeof(Foo),
typeof(Bar),
Generator.Foo,
Assertions.Foo);
yield return
new TestCaseData(
typeof(Bar),
typeof(Foo),
Generator.Bar,
Assertions.Bar);
}
[TestCaseSource(nameof(TestCases))]
public void CheckSomeTypes(
Type sourceType,
Type destinationType,
TSource source,
Action<object, object> assert)
{
GetType()
.GetMethod(nameof(CheckSomeTypesImpl), BindingFlags.Public | BindingFlags.Instance)
.MakeGenericType(new[] { sourceType, destinationType })
.Invoke(this, new object[] { source, assert });
}
public void CheckSomeTypesImpl<TSource, TDestination>(
TSource source,
Action<TSource, TDestination> assert)
{
var destination = Mapper.Map<TSource, TDestination>(source);
// Assert are equiviliant
assert(source, destination);
}
}
However, I believe the following design may add value in this instance:
[TestFixture]
public class SomeTests
{
public static IEnumerable<TestCaseData> TestCases()
{
yield return
new TestCaseData(
typeof(Foo),
typeof(Bar),
Generator.Foo,
Assertions.Foo);
yield return
new TestCaseData(
typeof(Bar),
typeof(Foo),
Generator.Bar,
Assertions.Bar);
}
[TestCaseSource(nameof(TestCases))]
public void CheckSomeTypes<TSource, TDestination>(
TSource source,
Action<TSource, TDestination> assert)
{
var destination = Mapper.Map<TSource, TDestination>(source);
// Assert are equiviliant
assert(source, destination);
}
}
public class Foo
{
public string Qux { get; set; }
}
public class Bar
{
public string Qux { get; set; }
}
public static class Generator
{
public static Foo Foo =>
new Foo { Qux = "TestTestTest" };
public static Bar Bar =>
new Foo { Bar = "AnotherAnotherAnother" };
}
public static class Mapper
{
// Generic mapper function
public static TDestination Map<TSource, TDestination>(TSource source)
{
if (typeof(TSource) == typeof(Foo))
{
return Map((Foo) source);
}
if (typeof(TSource) == typeof(Bar))
{
return Map((Bar) source);
}
throw new NotImplementedException($"No mapping for {typeof(TSource).FullName}.");
}
public static Foo Map(Bar bar)
{
return new Foo { Qux = bar.Qux };
}
public static Bar Map(Foo foo)
{
return new Bar { Qux = foo.Qux };
}
}
public static class Assertions
{
public static Action<Foo, Bar> Foo =>
(foo, bar) => Assert.AreEqual(foo.Qux, bar.Qux);
public static Action<Bar, Foo> Bar =>
(bar, foo) => Assert.AreEqual(bar.Qux, foo.Qux);
}
I have made extensions to TestCaseSourceAttribute
locally to support this.
Is this something open for a contribution? I want to clarify the design first before I create a PR.
Is this something open for a contribution? I want to clarify the design first before I create a PR.
Thank you very much for starting the conversation and offering the help. We want to clarify the design before you create a PR, too. =D It will likely end up open for a contribution soon!
Same ask but for TestCaseAttribute
, not TestCaseSourceAttribute
: https://github.com/nunit/nunit/issues/1215
Inference only: https://github.com/nunit/nunit/issues/150
I'm already having to write suboptimal code today, so I absolutely want this.
In the TestCaseData
constructor, do you think there's a way to more visually differentiate Type
values that fill generic method parameters from Type
values that fill ordinary method parameters?
For discoverability: what about new TestCaseData<T1, T2>(ordinaryArg1, ordinaryArg2)?
Or this, which would allow us to avoid declaring N new TestCaseData
classes:
TestCaseData.Create<T1, T2>(ordinaryArg1, ordinaryArg2, ordinaryArg3)
What about using a method like TestCaseData.GenericsArgs(params Type[] generics) similar to Returns method.
That could work too. @nunit/framework-team, anyone else find this topic interesting?
This issue is marked as an idea/design/discussion but hasn't had contributions in years so I am closing. If anyone is interested in working on this idea, post your interest and the team will consider reopening.
Most helpful comment
That could work too. @nunit/framework-team, anyone else find this topic interesting?