-
Notifications
You must be signed in to change notification settings - Fork 413
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
DGPv2 Android integration tests #3904
DGPv2 Android integration tests #3904
Conversation
Create integration tests for using DGPv2 with Android projects. Additionally, create a JUnit extension for helping set up and run the tests. #### Overview - DokkaGradlePluginTestExtension is a JUnit extension for automatically configuring and re-running tests. The behaviour can be configured by providing custom GradleTestProjectInitializer (for setting up the test projects), or custom GradlePropertiesProvider (for providing custom Gradle properties). - The extension will re-run the tests multiple times with different versions. `TestedVersions.testedVersions()` provides all possible, valid combinations of versions used to run the tests. - Add JUnit `@Tag` annotations, to help organise and categorise the tests. - Add two new test projects in dokka-integration-tests/gradle/projects: it-android and it-android-compose. Each project has an `expectedData` directory containing the expected generated Dokka content. - Split GradlePropertiesBuilder into separate class, so it can be re-used in the integration tests
…id detecting CC status via an absence of log output
Moving GradlePropertiesBuilder to a separate class will permit reusing it in Dokka integration tests that will be introduced in PR #3904
Moving GradlePropertiesBuilder to a separate class will permit reusing it in Dokka integration tests that will be introduced in PR #3904
Significantly improve comparison between directories. Currently the failure messages are too obscure, and hard to diagnose. Example: https://ge.jetbrains.com/s/vl2jgh3ivevyi/tests/task/:dokka-integration-tests:gradle:test/details/org.jetbrains.dokka.it.gradle.AndroidProjectIT/generate%20dokka%20HTML(DokkaGradleProjectRunner)%5B1%5D?top-execution=1
…m/feat/KT-70336/android-integration-tests # Conflicts: # dokka-integration-tests/gradle/src/testExampleProjects/kotlin/ExampleProjectsTest.kt # dokka-runners/dokka-gradle-plugin/build.gradle.kts # dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/kotestFiles.kt
…m/feat/KT-70336/android-integration-tests
e9a6f7c
to
de2834c
Compare
…m/feat/KT-70336/android-integration-tests
Moving GradlePropertiesBuilder to a separate class will permit reusing it in Dokka integration tests that will be introduced in PR #3904
# Conflicts: # dokka-runners/dokka-gradle-plugin/src/test/kotlin/utils/ShouldBeADirectoryWithSameContentAsTest.kt # dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/GradlePropertiesBuilder.kt # dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/kotestFiles.kt
``` configuration cache cannot be reused because the file system entry '../../../../../../../home/teamcity/android-sdk-linux/build-tools/34.0.0/aapt' has been created. ```
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.
Overall LGTM.
A lot of "magic" under the hood in junit setup (I don't have a lot of experince with writing custom extensions), but looks more or less understandable.
But I do really like how *IT.kt
files look: nice and clear (and kotest also helps here)!
Thanks for improving our IT even more!
dokka-integration-tests/gradle/projects/it-android-compose/settings.gradle.kts
Show resolved
Hide resolved
...s/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/GradleTestProjectInitializer.kt
Outdated
Show resolved
Hide resolved
...tegration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/TestedVersions.kt
Outdated
Show resolved
Hide resolved
...tegration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/TestedVersions.kt
Outdated
Show resolved
Hide resolved
...tegration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/TestedVersions.kt
Outdated
Show resolved
Hide resolved
...tegration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/TestedVersions.kt
Outdated
Show resolved
Hide resolved
...tegration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/TestedVersions.kt
Outdated
Show resolved
Hide resolved
dokka-integration-tests/gradle/src/main/kotlin/org/jetbrains/dokka/it/gradle/junit/testTags.kt
Outdated
Show resolved
Hide resolved
project.runner | ||
.addArguments( | ||
":dokkaGenerate", | ||
"--build-cache", |
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.
tests appears to be testing only up-to-date checks on re-run.
why build cache is needed here?
shouldn't we also tests for some "changes" in outputs or inputs?
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.
Thanks, good point, I've updated the assertions to test the actual Dokka generation work tasks, not just the dokkaGenerate
lifecycle task (which is not cacheable since it has no inputs/outputs).
project.runner.addArguments( | ||
"clean", | ||
":dokkaGenerate", | ||
"--no-build-cache", |
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 is it necessary to specify "no build cache" here? I though configuration cache can work without knowing anything about build cache as it is more related to execution phase.
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.
Hmmm I suppose disabling build cache not strictly necessary, but I can imagine that a buggy Gradle task might produce some uncached output that could disrupt CC.
TBH I can't remember why it's there. Perhaps it could be removed, but I don't think it does any harm.
} | ||
|
||
@DokkaGradlePluginTest(sourceProjectName = "it-android") | ||
fun `expect Dokka is compatible with Gradle Configuration Cache`( |
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.
also it looks like AndroidComposeIT and AndroidProjectIT have shared code. Is it ok for you to keep those duplicated? i.e. you don't see lots of maintenance with this code in the future.
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.
Yes, quite a lot of the tests are duplicated. I intend to add more tests KT-71163, but I don't want to pre-emptively optimise and start deduplicating code just yet. I'd rather add more tests, and then see what could be extracted out.
The setup and test assertions for Android projects is more complicated than most other projects, so I'd prefer to hold off on trying to DRY until some more basic projects are tested.
- Make TestedVersions more strict, with specific subclasses for the Android and AndroidCompose tests. - Split out TestedVersions generation into TestedVersionsSource.
…am/feat/KT-70336/android-integration-tests
Create integration tests for using DGPv2 with Android projects.
Additionally, create a JUnit extension for helping set up and run the tests.
Part of KT-70855 - the HTML currently contains errors, but this will be resolved in later PRs.
Overview
DokkaGradlePluginTestExtension is a JUnit extension for automatically configuring and re-running tests.
The behaviour can be configured by providing custom GradleTestProjectInitializer (for setting up the test projects),
or custom GradlePropertiesProvider (for providing custom Gradle properties).
The extension will re-run the tests multiple times with different versions.
TestedVersions.testedVersions()
provides all possible, valid combinations of versions used to run the tests.Add JUnit
@Tag
annotations, to help organise and categorise the tests.Add two new test projects in dokka-integration-tests/gradle/projects: it-android and it-android-compose.
Each project has an
expectedData
directory containing the expected generated Dokka content.Split GradlePropertiesBuilder into separate class, so it can be re-used in the integration testsMoved to separate PR
Move GradlePropertiesBuilder test util to separate class #3906
Tip
This PR contains the expected HTML files, which make the PR difficult to view in GitHub.
You can filter out the files in the GitHub UI: