-
-
Notifications
You must be signed in to change notification settings - Fork 821
Simplify TestConfig usages
#5801
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
Conversation
9f5aa83 to
2303048
Compare
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Fixed
Show fixed
Hide fixed
...es-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/BracesOnIfStatementsSpec.kt
Fixed
Show fixed
Hide fixed
...les-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/ForbiddenMethodCallSpec.kt
Fixed
Show fixed
Hide fixed
...les-style/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/style/ForbiddenMethodCallSpec.kt
Fixed
Show fixed
Hide fixed
detekt-test/src/main/kotlin/io/gitlab/arturbosch/detekt/test/TestConfig.kt
Fixed
Show fixed
Hide fixed
detekt-test/src/main/kotlin/io/gitlab/arturbosch/detekt/test/TestConfig.kt
Fixed
Show fixed
Hide fixed
Codecov Report
@@ Coverage Diff @@
## main #5801 +/- ##
=========================================
Coverage 84.59% 84.60%
- Complexity 3789 3790 +1
=========================================
Files 546 546
Lines 12918 12918
Branches 2268 2268
=========================================
+ Hits 10928 10929 +1
+ Misses 862 861 -1
Partials 1128 1128
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
2303048 to
9135db9
Compare
9135db9 to
777e9fc
Compare
TWiStErRob
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice one! Pushed a small commit (it was easier to fix them than to call them out on GitHub)
Some questions as conversations, please review them.
...plexity/src/test/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/ComplexInterfaceSpec.kt
Outdated
Show resolved
Hide resolved
|
|
||
| companion object { | ||
| @Suppress("DEPRECATION") | ||
| operator fun invoke(vararg pairs: Pair<String, Any>) = TestConfig(mapOf(*pairs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move this to be a constructor? and deprecate the invoke too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷 I don't know what benefits would provide us that. But I think that could be done in a different PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thinking about the future, since the map constructor is deprecated now, I would imagine it will be hidden eventually, which means that there won't be a way to construct TestConfig directly, only through the factory method in the companion object, which is strange considering the same could could be just a constructor. Since the constructor gets deprecated now, I think maybe it would be good to deprecated the companion invoke as well, and create a constructor with the same signature. Ideally the overload resolution would just pick the new constructor and give us source compatibility and keeping the invoke method as a deprecated one would give us binary compatibility for public users.
detekt-test/src/main/kotlin/io/gitlab/arturbosch/detekt/test/TestConfig.kt
Show resolved
Hide resolved
detekt-test/src/main/kotlin/io/gitlab/arturbosch/detekt/test/TestConfig.kt
Show resolved
Hide resolved
4999a4a to
7c89295
Compare
7c89295 to
5bc0ad4
Compare
In nearlly all our tests we use
TestConfig(Map<String, Any>). This make us write code like this:The
mapOfprovide us really little value there and only increase the verbosity. I changed all our test to useTestConfig(vararg Pair<String, Any>)it does exactly the same but the code is a bit easier:I also deprecated the old version to promote this new one. I can't remove it because it is part of our public API.