https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
s
For example, I have a task that modifies the inputs to 
maven-publish
tasks which leads to a few files changing. My assertions are manually parse the output files to determine if the changes reflect. The API provided by testkit can help confirm the task status. But it would be great if I could check the config setup for the task too.
v
Maybe have a task that validates the other tasks config and call that in your test, validating that it was successfully run?
s
Hmm.This task would then be created by the plugin? If I understand you correctly, this would work, but I’d not be able to use this with the usual junit assertions. My validation task could either succeed or fail and the error handling and correct messaging would need to be a part of that task, instead of leveraging the test framework here.
Would you also have any references I can use for plugin tests to understand if I’m approaching the problem incorrectly? Preferably in kotlin/java 😅 . I see groovy to be the preferred language for testing with TestKit
v
Unfortuantely not, no, was just an idea how you could approach it. And no, I didn't mean that task to be created by the plugin, but to be part of your test build script. You can also have multiple tasks to test different aspects of the changes either in different tests or in the same test. Regarding writing tests in Java / Kotlin, when I first contributed to Gradle itself, I was forced to learn how to use Spock for testing to test my changes. Now I'm more than happy I was and exclusively use Spock for any tests wherever possible. Spock is what makes testing fun again instead of a burden. 🙂 But Spock is the one that enforces Groovy. You can probably use TestKit just fine with Kotlin or Java, but my recommendation would actually be to embrace Spock instead and cope with it being Groovy-based. Luckily almost any valid Java code is also valid Groovy code, so you could actually write your test code "Java-like" even if it then is bad practice. 🙂
s
Thanks , let me look into having a task created as a part of the test script. On using spock, I’m sold based on what your feedback and reading tests written in Spock 🙂 . It reminds me of Spek . My reasons for doing this in Kotlin/Java right now is to reduce the entry barrier for writing tests for other folks in my team. I’ll start with writing tests in Spock on personal/smaller projects and then hopefully get my teammates to use it too 🙂 .
v
Latest when it comes to writing data driven tests or the integrated mocking and stubbing, they will be caught too. :-)
Well, actually, the thing I love most are the failures. You don't need to take any measures like using extensive Hamcrest API or similar to get helpful assertion failures, you just write simple statements and you automatically see each steps value if it fails. A slightly stripped down version of the power assertions was even integrated into Groovy itself after they have seen their beauty in Spock. :-)
j
you can use ProjectBuilder
Copy code
val rootProject = ProjectBuilder.builder()
            .build() as ProjectInternal
val subProject = ProjectBuilder.builder()
            .withParent(rootProject)
            .build() as ProjectInternal

subProject.plugins.apply(JavaPlugin::class.java)
subProject.plugins.apply(MyPlugin::class.java)

subProject.evaluate()
rootProject.evaluate()

assertThat(subProject.tasks.getByName("myTask")).isNotNull()
it lets you get the actual task objects, and interact with a project just like how you would in a plugin / buildscript
v
Yeah, more unit tests then, than functional tests like with testkit 🙂
s
TIL about ProjectBuilder. Which will check that out. Thank you 🙂.
My immediate goal was to have some functional tests in place to prevent regressions and I love testkit for that! Will explore what other approaches to use for testing gradle plugins going forward.
Does ProjectBuilder have a user manual / documentation on best practices/ usage?My google fu only leads me to the javadcocs https://docs.gradle.org/current/javadoc/org/gradle/testfixtures/ProjectBuilder.html
j
I use the javadoc. One gotcha is, try to avoid tests that would cause dependencies to resolve. They tend to be flaky on file locking issues
👀 1
2 Views
Open in Slack
PreviousNext
Powered by