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

integration tests #253

Merged
merged 2 commits into from
Jan 20, 2021
Merged

integration tests #253

merged 2 commits into from
Jan 20, 2021

Conversation

ting-yuan
Copy link
Collaborator

No description provided.

@ting-yuan ting-yuan requested a review from neetopia January 16, 2021 08:03
@ting-yuan
Copy link
Collaborator Author

Will enable CI in another PR later.

@ting-yuan ting-yuan requested a review from gavra0 January 16, 2021 08:06
@ting-yuan ting-yuan force-pushed the kspIT branch 2 times, most recently from 15765ba to 4f698b6 Compare January 17, 2021 09:25
Copy link
Contributor

@gavra0 gavra0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good IMHO, just minor comments.

fun OutputStream.appendText(str: String) {
this.write(str.toByteArray())
}
class BuilderProcessor : SymbolProcessor {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you get symbol resolution when writing these tests? If not, I'd consider moving them to a separate project, and make it depends on ksp. Then you can publish these processors to the test repository, and just depend on them from the integration projects.

If there is already IDE support, feel free to ignore my comment.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. No, IDE doesn't work well with the processors. Will do in a separate patch after supporting specifying a single processor in a shared jar.


@Test
fun testPlayground() {
val gradleRunner = GradleRunner.create().withProjectDir(testProjectDir)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't used GradleRunner before. Does each test JVM fork starts its own Gradle daemon?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the doc, yes, although I didn't verify it.
https://docs.gradle.org/current/userguide/test_kit.html#sec:controlling_the_build_environment

An observation from another perspective is that it's a bit slow to start. For integration tests that involves Gradle, I guess I can accept it, though.

@ting-yuan ting-yuan merged commit 8bbcc6d into google:master Jan 20, 2021
@ting-yuan ting-yuan deleted the kspIT branch October 11, 2024 02:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants