Test File Inclusions: One or more wildcard patterns defining which files to retain, while filtering out all others, from those defined by sonar.tests. This can also be set in a configuration file using the key sonar.test.inclusions.
So setting sonar.test.inclusions to **/Tests/** is not going to cover something in E2ETests.
What about
sonar.test.inclusions=**/Tests/**,**/E2ETests/**?, or dropping sonar.test.inclusions entirely (the source sets being defined in sonar.tests is enough)
One folder for main target unit tests $SRCROOT/ProjectNameTests
One folder for main target e2e tests $SRCROOT/E2ETests
Many folders for monorepo frameworks $SRCROOT/**/Tests
setting sonar.test.inclusions to **/Tests/** is not going to cover something in E2ETests
I was expecting that including E2ETests into sonar.tests is enough to skip that folder entirely and recursively. I can’t get why it isn’t.
What about sonar.test.inclusions=**/Tests/**,**/E2ETests/** ?
I can move all my folders with tests into sonar.test.inclusions. But what should I do with sonar.tests? Should I completely omit this parameter? Is sonar.test.inclusions selfsufficient?
or dropping sonar.test.inclusions entirely
In our project, the structure of folders and files is such that it is easier to specify folders with tests using wildcards than to specify all folders with source codes.
Because you are also setting sonar.test.inclusions. sonar.test.inclusions further narrows the set of files being passed to sonar.tests
No, you also need to have sonar.tests set.
Then you can also set both sonar.sources and sonar.tests to . and then use a wildcard pattern with sonar.test.inclusions like **/Tests/**,**/E2ETests/**,/ProjectNameTests/`