-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Category as filter not working in single agent flow in vstest task #495
Comments
I would prefer that VSTest mapped the category attribute to TestCategory traits at the vstest/TestPlatform level. NUnit doesn't have traits; it has properties, and they are not translated 1:1 into traits for different reasons. |
@jnm2 Sorry I have used traits instead of attribute. Will refactor that in all the comments. |
@abhishkk Just so I know what we're talking about, where are you getting the string If so, why not make a rule in VSTest that interprets Down the road, I am hoping NUnit can take responsibility for the static analysis, used for example in realtime test discovery. (nunit/nunit#2733) NUnit has a lot of subtleties and is still changing. If we went this direction, we'd provide you an assembly where you pass in something like Roslyn syntax nodes and we spit out something like TestCase instances, set up properly with knowledge from both the NUnit Framework and NUnit VS adapter repositories. |
Correct.
We have already done this. Please check this comment for more details. In in-built adapters of VS, TestCategory is the filter name because attribute name there is TestCategory. NUnit adapter today understands TestCategory as filter just because VS in-built adapters do so. This should not happen. NUnit filter name should be driven through their respective attribute name. In vstest, any user expect filter to be passed as per attribute name. As vstest is used for various adapters, it is better to use Category as filter to avoid confusion. |
Thank you, that's a great explanation! This makes sense; rather than being about TIA per se, VSTest officially wants all adapters to support only their own names as traits under all circumstances. If @OsirisTerje and @rprouse support this VSTest guidance, going ahead sounds awesome to me so long as we document that everyone should use |
@abhishkk Whether one want to use a common name or a specific name depends on your situation. Given that a system is having a mix of two frameworks, for whatever reason (legacy, moving from one to another), it makes sense to have a common naming too, so that the devops people don't need to worry about whether the underlying code uses one or the other framework. For situations where the opposite is true, a single framework is being used, it makes more sense to use that frameworks "native" names. |
Very good point. We should support |
Filters are adapter specific and not test platform specific. In case multiple adapters are used in a run, we expect user will pass filters for both. Example: But as vstest and VS TestPlatform, we allow both:
The reason changes are done from our side in NUnit is because we were doing filtering at our end in few scenarios like TIA (which we should avoid as filtering should be done by adapters and not by TestPlatform). Filtering was done at our side as we needed discovery time filtering which was not supported for adapters at that time. Recently, I have added support for disocvery time filtering in TestPlatform as well. This will make filtering totally on adapters for all flows. We will send guidelines and raise issue in near future regarding the same. |
Issue
While running NUnit tests from vstest task, we can run tests in:
For 2nd and 3rd scenario, there comes a requirement in which tests needs to be filtered out at discovery time. As discovery time filtering was not supported for adapters till now (its supported now), TestPlatform filters tests at discovery on its own for these scenarios.
While doing filtering at discovery time, TestPlatform has exact mapping of Filters to traits. i.e. For Category trait, Category filters is understood.
Thus behavior change in TestPlatform side filtering(understand Category filter for Category trait) and adapter side filtering(understand TestCategory filter for Category trait) forces users to use
Sample Issues
Few of the issues related to this are:
The text was updated successfully, but these errors were encountered: