Skip to content
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

Make skipTestGroups resolution logic configurable #270

Closed
mcwhitak opened this issue Jun 27, 2022 · 5 comments
Closed

Make skipTestGroups resolution logic configurable #270

mcwhitak opened this issue Jun 27, 2022 · 5 comments
Labels

Comments

@mcwhitak
Copy link

Currently skipTestGroups operates on the implicit prefixes of test and androidTest (the other explicit matches don't end up mattering since they meet these prefixes).

It would be helpful if these prefixes could be configurable so that new test sourceSets of the form xTest (ex: integrationTest, functionalTest, acceptanceTest) could be excluded easily from scans.

Alternatively having a regex option here would also help (to just be able to exclude anything with .*Test.* or .*test.* ) but I understand if that's too large of a change.

Would be happy to do the work for this, just looking for the direction you would like to go before starting (I'm guessing an additional extension ListProperty<String> that would default to test, androidTest.

@chadlwilson
Copy link

I imagine you could achieve this already by using something like the below in your configuration rather than relying on the special opinionated skipTestGroups handling? (Or just enumerate them yourself in an array)

dependencyCheck {
  skipConfigurations = configurations.findAll { it.name ==~ /(?i).*test.*/ }.collect { it.name }
}

@GALHP
Copy link

GALHP commented Jan 3, 2024

A customizable boolean isTestConfiguration(Configuration configuration) would be really helpful for Kotlin Multiplatform projects, where tests rely on sourceSets like commonTest, iosTest, androidTest, ...

And so all the configurations in hierarchy will not match test*

@chadlwilson
Copy link

I don’t really understand why you can’t do whatever you like using an example like I gave above to dynamically populate skipConfigurations? Essentially that fragment is a customisable isTestConfiguration, no - write the equivalent in Kotlin?

@GALHP
Copy link

GALHP commented Jan 3, 2024

Yes, you are totally right. I didn't get this dynamic approach the first time I read it. And due to the fact that the ticket is still open, I did my post.

After reading #22, i understood your nice one liner.

Maybe both of these should not be open anymore?

@jeremylong
Copy link
Collaborator

resolved with comment #22 (comment). Leaving #22 open for now as documentation - until I get a chance to update the official documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants