Multiple Test Cases Use Inputs from First Case

[EvanGeer]

For example, the test below runs three times with the values from the first case, 12, 3 and 15, but does not iterate through the others.

[EvanGeer]

I have a fix coded, and PR submitted.

Basically I am passing the iterator's index for the multi-case tests to the ReflectionRunner and then using that index to get the correct test case params.

[tobiasfloescher-geberit]

Hi, yes you are totally right, this doees not work correctly. Thank you for the PR. But I have noticed two problems:

• There is no assert of the ExpectedResult
• If run only one of the Cases, still the first arguments are passed (12, 3 from the example above)

I will take this in the backlog.

In meanwile, I would recomend using different Test methods, which calling an assert method.

[Test]
public void SumTest1() => Sum( 12, 3, 15 );

[Test]
public void SumTest1() => Sum( 13, 7, 20 );

[Test]
public void SumTest1() => Sum( 15, 4, 19 );

private void Sum( int n, int d, int expectedResult )
{
     Assert.AreEqual( n + d, expectedResult );
}

[EvanGeer]

Ah, good call for a workaround. I will likely still implement a fix on our end to address the assert issue. I may also take a stab at the run once issue as well, since at the root, it might be solved by taking a crack at the timing problem. If I get something workable, I will share with you.

Side note, this is an awesome product, and I am happy to help develop it. Your implementation (leveraging the idling event to call a test runner) is exactly what I had in mind to build for our team, so I am super excited that you have already done so and shared your solution. If you have any ideas in the pipeline for dev work, I am happy to pick some things up and run with them in my spare time.

[EvanGeer]

FWIW, this is the test case I was building off of, which is another viable workaround:

        [TestCase("99999 123")]
        [TestCase("99999 2")]
        [TestCase("99999 3")]
        public void Cases(string text)
        {
            Assert.That(TaskDialog.Show(text, $"{text}!!!") == TaskDialogResult.Close);
        }

[tobiasfloescher-geberit]

Ah, I see your case, no ExpectedResult needed ;) Happy to hear, that you like the product. Feel free to share your solution, thank you.

[tobiasfloescher-geberit]

I had a look at the problem and I refactored the ReflectionController, because it was little bit a mess ;) But I have decided to skip the TestCase feature in general for the moment, because it is not correct implementable with the current architecture. Now a NotSupportedException is thrown. It's now documented. Sorry for the bad news.

It must be somehow passed by the request, which TestCase attribute should be use. Otherwise, the ReflectionController has no idea which one to execute, 1,2,3, or 1,3, or only 2, ... Index is not precise enough.

But you are not the first person requesting this, if you have a stable solution, let me know ;) At least a workaround exist.