Does "Arguments" really have to be its own attribute?

[MelGrubb]

I am unfamiliar with the internals, so this may be a question out of ignorance here. Is there any reason that the duties of the Arguments attribute couldn't be handled by the Test attribute?

For instance, instead of

    [Test]
    [Arguments(1, 1, 2)]
    [Arguments(1, 2, 3)]
    public async Task MyTest(int value1, int value2, int expectedResult)
    {
    ...

you'd say

    [Test(1, 1, 2)]
    [Test(1, 2, 3)]
    public async Task MyTest(int value1, int value2, int expectedResult)
    {
    ...

Yes, you have two Test attributes now, but you really are describing two separate tests here, so it seems to more accurately describe the situation to me. The same could perhaps be done for MethodDataSource

    [Test(typeof(MyTestDataSources), nameof(MyTestDataSources.AdditionTestData))]
    public async Task MyTest(AdditionTestData additionTestData)
    {
    ...

"This is a test, and the parameters come from over there."

Again, I'm unfamiliar with the wiring under the covers, and maybe there's something that makes this impossible. From a readability perspective, though, it seems like what you're really doing is describing a test, so the data for that test would belong on the test attribute. This may just be wishful thinking, really. It's a thing that has bothered me about other test frameworks. Multiple attributes may make the framework easier to maintain, but the majority of the interaction with any testing framework is from the consumption side. Eliminating friction for the user OF the library would be my highest priority.

[thomhurst]

Thanks for the feedback. Unfortunately if I did this, if I had a

[Test(typeof(SomeClass), nameof(SomeMethod)) and there was a method that was void Test(Type type, string value) then how would I know to pick arguments, or a method source?

By keeping them separate we avoid ambiguity and things potentially being wired up unexpectedly.

Also the test attribute has two invisible parameters that are compiler generated, which further complicated things.

So hope that helps explains those decisions.

[MelGrubb]

True, and I understand the reasoning, even if it makes me sad. I'd say "named arguments", but that starts to destroy the readability I was after.