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.