-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Introduce support for filtering packages #313
Comments
When specifying filters for packages we have different options how to evaluate the filter rules:
The advantage of having one filter over two different filters is, that it could evaluate all filter rules allowing to specify more granulate filter rules. The advantage of having two separate filters is, that the filters itself are simpler and better to maintain. Therefore, we prefer option 4 in favor to option 2 in case of simplicity. We can discuss the other options using the following example and see have the filter rule are applied and what the outcome is. ExampleGiven the following filter rules:
Filtering with Option 1
Note:
Filtering with Option 2
Note:
Filtering with Option 3
Note:
Filtering with Option 4
Note:
Quick option comparison
ConclusionThe most natural option would be Option 1. Its result seem to be the most obvious solution from a user perspective of the filtering. It allows to specify fine granulate rules and overriding on any level, e.g. Option 3 has a lower complexity and almost the same filter results. There is only one case Option 2 will lead to unexpected filter results if we define the outcome of the undefined cases to be included. Therefore, if should return exclude in these case, making the outcome of the filter evaluation exact equally with Option 4. We are in favour of option 4 in this case because of its simplicity over option 2. RecommendationOne should go for Option 1 or Option 3, depending on whether or not one wants to be able to overrule previously defined exclude rules for sub packages. If JUnit should support this, then Option 1 is the best solution. If this is not required, Option 3 is the better solution, as it is much easier to implement, understand, and maintain. |
Team decision: Follow the recommendation and start with option 3. |
Merged into master with #570 |
Thanks, @bechte! 👍 |
Status Quo
It is currently possible to select a package -- for example, for classpath scanning. However, it is not possible to filter packages.
See use case described in #534 for additional input.
Related Issues
Deliverables
PackageFilter
class (similar toClassFilter
).JUnitPlatform
runner (e.g.,@IncludePackages
and@ExcludePackages
).The text was updated successfully, but these errors were encountered: