Feature request: Provide interface to query selected categories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NUnit V2 |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Please implement a feature that will provide a list of which categories have been chosen for the test run (using the include list).
Here's a code sample of how this could be used in future:
TestContext.
[Test]
[Category("long")]
[Category("short")]
Public void SomeTest()
{
List.Add(item1);
List.Add(item2);
If(TestContext
{
List.Add(item3);
List.Add(item4);
...
List.Add(itemN);
}
ProcessList(List);
}
Depending on the content of the list, this test might either take an hour (full scope) or 2 minutes (reduced scope).
This feature request has been filed as a result of a discussion in NUnit discuss group:
http://
Changed in nunitv2: | |
status: | New → Triaged |
importance: | Undecided → Low |
milestone: | none → 2.6.0 |
Changed in nunitv2: | |
importance: | Low → Undecided |
Changed in nunitv2: | |
milestone: | 2.6.0 → none |
On the surface, this makes sense, but after further analysis there are some issues...
1. When no categories are selected, all tests are run but SelectedCategories will be empty. This could be handled by the user checking for an empty list.
2. Categories may also be excluded. We would need to provide a separate list for these categories and the user would have to test it as well. So the test would become something like... SelectedCategor ies.Contains( "long") && !TestContext. ExcludedCategor ies.Contains( "long) )...
If ( TestContext.
with added logic to handle empty lists, depending on what the user wanted to accomplish.
3. A category expression may be provided, like A + B - C. This cannot be expressed as a simple list so the user would be forced to duplicate NUnit's parsing of the expression. Further, this expression syntax is likely to change in the next version of NUnit.
I'm open for suggestions on how to deal with these problems, either from the original proposer or from others.
An alternative is to use the TestCaseSourceA ttribute to provide data. We have recently added a Category property to that attribute, allowing the example to be rewritten as follows:
IEnumerable shortData = new object[] { item1, item2 };
IEnumerable longData = new object[] { item3, item4, ... , itemN }
[TestCaseSource ("longData" , Category="long")] ("shortData" , Category="short")] List<SomeType> list)
[TestCaseSource
Public void SomeTest(
{
ProcessList(List);
}
This seems to me to solve all the problems and eliminate the need for the requested feature. Thoughts?