VSoftTechnologies/DUnitX

ITestDataProvider.GetCaseName should have param for the case number

Closed this issue · 2 comments

I've recently started using test case providers, very cool! The only thing I find less productive is the way in which GetCaseName() functions. It's currently called like so...

count := iProvider.GetCaseCount(method.name);
caseName := iProvider.GetCaseName(method.name);
for x := 0 to count -1 do
begin
  params := iProvider.GetCaseParams(method.name,x);
  for i := 1 to repeatCount do
  begin
    currentFixture.AddTestCase(method.Name, FormatCaseName(caseName,x), FormatTestName(method.Name, i, repeatCount), category, method, testEnabled, params);
  end;
end;

...but I think it would be better if changed to accept the current test case number, moved into the loop, and abandon the current FormatCaseName()...

count := iProvider.GetCaseCount(method.name);
for x := 0 to count -1 do
begin
  caseName := iProvider.GetCaseName(method.name,x);
  params := iProvider.GetCaseParams(method.name,x);
  for i := 1 to repeatCount do
  begin
    currentFixture.AddTestCase(method.Name, caseName, FormatTestName(method.Name, i, repeatCount), category, method, testEnabled, params);
  end;
end;

This brings it more in line with defining test cases without a provider where I can give each a unique and meaningful name.

[Test]
[TestCase('File1.txt', 'C:\File1.txt')]
[TestCase('File2.txt', 'C:\File2.txt')]
[TestCase('File3.txt', 'C:\File3.txt')]
procedure VerifyANSIEncoding(AFilename: string);

We have a few different use cases where we're using providers to serve up dynamic content (including iterating files in a folder) and being able to assign a more meaningful test case name as we can with the TestCase attribute would be powerful.

Using logging messages would be a local workaround, but they don't find their way into the NUnit XML report used by our build plan.

I'll leave this here as a suggested enhancement. I would be more than happy to make the change and submit pull request, but I'd need your opinion on whether or not it should be breaking change or supplemental. I think it should break existing logic so that it matches the logic when defining cases using TestCase attribute.

Thanks,
Michael

Hi Michael

I'm not against this idea, let's see what @UweRupprecht thinks since he was the contributor who created the TestCaseAttribute.

Feel free to submit a PR for this, can't promise it will get merged but I will look at it.
Vincent.

No PR eventuated so closing this.