orion0616 opened a new issue, #3465:
URL: https://github.com/apache/maven-surefire/issues/3465

   ### Affected version
   
   3.6.0 (also 3.6.0-M1). Works with 3.5.6.
   
   ### Bug description
   
   Minimal reproducer: https://github.com/orion0616/surefire-includes-repro 
(one Jupiter test `com.example.it.SampleIT`, failsafe configured with 
`<include>com/example/it/**/*IT.java</include>`)
   
   ```
   mvn verify -Dsurefire.version=3.5.6   # Tests run: 1
   mvn verify -Dsurefire.version=3.6.0   # Tests run: 0, BUILD SUCCESS
   ```
   
   | `<include>` | 3.5.6 | 3.6.0 |
   | --- | ---: | ---: |
   | `com/example/it/**/*IT.java` | 1 | **0** |
   | `**/it/**/*IT.java` | 1 | **0** |
   | `%regex[.*SampleIT\.class]` | 1 | **0** |
   | `**/*IT.java` | 1 | 1 |
   | `com/example/it/*IT.java` | 1 | 1 |
   
   With `-X`, 3.6.0 still logs `Tests to run: [com.example.it.SampleIT]` and 
starts the fork, so the class is dropped inside the fork, not by the scanner. 
Same result with JUnit 5.14.1 and 6.0.3. Both pattern forms are documented as 
supported (the docs use `pkg/**/*Fast*.java` as an example, and say 
`%regex[...]` is matched against `.class` paths with slashes): 
https://maven.apache.org/surefire/maven-failsafe-plugin/examples/inclusion-exclusion.html
   
   This looks like the provider-level `ClassNameFilter` added in #3179 
(`JUnitPlatformProvider#newFilters`, the same area as #3446). The scanner-style 
patterns are matched against dotted class names: the `/` to `.` replacement is 
commented out, and after the fallback replacement in `matchClassName` an 
intermediate `**` requires a literal `.`, so `com.example.it.**.*IT` never 
matches `com.example.it.SampleIT`. `%regex[...]` is passed to 
`ClassNameFilter.includeClassNamePatterns`, i.e. applied to class names instead 
of class file paths. Matching the class file name the way the scanner does, 
e.g. `TestListResolver.shouldRun(TestListResolver.toClassFileName(className), 
null)`, would keep both filters consistent.
   
   In our project this silently turned 185 integration tests into 0 with a 
green build, since `failIfNoTests` defaults to false.
   
   I have a fix with unit and integration tests in progress and will open a PR 
shortly.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to