-
-
Notifications
You must be signed in to change notification settings - Fork 771
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
Modularize test module #2720
Modularize test module #2720
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2720 +/- ##
============================================
- Coverage 80.55% 80.55% -0.01%
- Complexity 2317 2323 +6
============================================
Files 378 380 +2
Lines 6928 6941 +13
Branches 1255 1256 +1
============================================
+ Hits 5581 5591 +10
- Misses 721 723 +2
- Partials 626 627 +1
Continue to review full report at Codecov.
|
LogExecuting kotlinc -script-templates systems.danger.kts.DangerFileScript -cp /usr/local/lib/danger/danger-kotlin.jar -script /Dangerfile.df.kts /tmp/danger-dsl.json danger_out.json - pid 377
Uncaught Kotlin exception: kotlin.Exception: Command kotlinc -script-templates systems.danger.kts.DangerFileScript -cp /usr/local/lib/danger/danger-kotlin.jar -script /Dangerfile.df.kts /tmp/danger-dsl.json danger_out.json exited with code 768
at kfun:systems.danger.cmd.Cmd.exec() (0x21c739)
at kfun:systems.danger.cmd.dangerfile.DangerFile.execute(kotlin.String;kotlin.String) (0x21d227)
at kfun:systems.danger.DangerKotlin.run() (0x21c0e6)
at Init_and_run_start (0x21f472)
at __libc_start_main (0x7f8f290cdb97)
at (0x20f029)
at ((nil))
|
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.
Why do you need an empty .css
in the test resources? detekt-parser/src/test/resources/css/test.css
There are not enough reactions to show the joy of this PR. Great boost!
* A comment | ||
*/ | ||
@Suppress("Unused") | ||
class Default |
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.
Shouldn't be better to inline this code?
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.
KtCompiler works on Path
objects.
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.
The empty css file is also to test KtCompiler ^^
implementation(kotlin("script-util")) | ||
implementation(kotlin("scripting-compiler-embeddable")) | ||
implementation("org.assertj:assertj-core:${Versions.ASSERTJ}") | ||
api(project(":detekt-test-utils")) |
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.
Probably same here. If you need both you can always add both as dependencies. I think that it's better to be explicit.
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 considered this but our tests use to many dependencies from test-utils for now.
I consider hiding this dependency from the sample-extension build file vital for now.
requireNotNull(resource) { "Make sure the resource '$name' exists!" } | ||
return resource.toURI() | ||
} | ||
fun resource(name: String): URI = io.github.detekt.test.utils.resource(name) |
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.
This function is here because you don't want to create a BC, right?
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.
Hm, no just to not need to modify all test files for now.
We never said that detekt-test
is api or publicly supported, just mentioned it in the sample-extension build file :/.
I will migrate the resource
usages in another PR.
We should try not to break functions like Rule.lint
as they are more likely used.
@@ -0,0 +1,9 @@ | |||
dependencies { | |||
api(kotlin("stdlib-jdk8")) | |||
api("org.assertj:assertj-core:${Versions.ASSERTJ}") |
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.
Why don't just use implementation
?
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.
AssetJ is our assertion library and therefore is used in every module.
We would have to declare it in 10+ modules.
LogExecuting kotlinc -script-templates systems.danger.kts.DangerFileScript -cp /usr/local/lib/danger/danger-kotlin.jar -script /Dangerfile.df.kts /tmp/danger-dsl.json danger_out.json - pid 378
Uncaught Kotlin exception: kotlin.Exception: Command kotlinc -script-templates systems.danger.kts.DangerFileScript -cp /usr/local/lib/danger/danger-kotlin.jar -script /Dangerfile.df.kts /tmp/danger-dsl.json danger_out.json exited with code 768
at kfun:systems.danger.cmd.Cmd.exec() (0x21c739)
at kfun:systems.danger.cmd.dangerfile.DangerFile.execute(kotlin.String;kotlin.String) (0x21d227)
at kfun:systems.danger.DangerKotlin.run() (0x21c0e6)
at Init_and_run_start (0x21f472)
at __libc_start_main (0x7ff694d82b97)
at (0x20f029)
at ((nil))
|
After upgrading to 1.10.0, due to this change I expect, I got the following error:
I had to add a dependency on
Don't know whether this was intentional. Just thought I'd share this problem I ran into in case others encounter it. |
Thanks for reporting. If its parsing content you could use |
I was just using EDIT: |
@Whathecode are you using Spek as testing framework? Line 16 in b6e88a9
I've created #2871 to hide KtTestCompiler from users. There will be an alternative for testing rules which need type resolution. |
Nope, I am using |
This "huge" PR (mostly import changes) splits the
detekt-test
module into two modules.detekt-test
remains the module used for testing rules.The new
detekt-test-utils
module is more lightweight in module dependencies.This module specializes in utility classes and parsing kotlin files for tests.
The problem with the
detekt-test
module:detekt-test
depends on "all" compile tasks of other detekt-modules but is the requirement for all test compile tasks! This means it is not only the bottle-neck for parallel build but also triggers all tests on nearly any change (especially gradle-plugin tests with runtime of 2.5m!!!)!This first change in test dependencies gets rid of the
detekt-test
dependency ongenerator
,gradle-plugin
andmetrics
modules.This leads to less triggering of the gradle tests (!!!) and these modules can be executed earlier in parallel builds (20s earlier gradle plugin testing, see screenshot).
In further non-breaking modularization effors for #2680, I want to get rid of the
detekt-test
dependency forcli
,core
and theapi
modules leading to less retriggering of tests.While this change does not necessary lead to performance improvements for a clean build, it will for incremental builds. This may improve CI build times as more test tasks can be cached.
In a breaking 2.0 release we could rename
detekt-test
todetekt-rule-testing-support
or something to make it's name more clearer.