This message was deleted.

I have some “sample” projects which contains a full build.gradle.kts (i.e. https://github.com/2BAB/Caliper/tree/main/caliper-gradle-plugin/src/fixtures/android-test-sample), however it does not link to current project structure, thus no code highlight/completion still. I guess the idea plugin could potentially add it to the IDE recognition path and then maybe treat it as a standalone script to gain some highlight/completion features from IDE.

I think all approaches are valid depending on what you want to test and what you find easier to maintain. For what you ask, I have used these two approaches in the past: 1. There is a test runner library– Exemplar – (also from Gradle) that you can use to test examples without writing test code at all 2. Write tests with Gradle's test kit, but load example builds from a folders as test data by copying them into a tmp folder in the test setup() Example for 1: https://github.com/gradlex-org/java-ecosystem-capabilities/blob/main/src/test/java/org/gradlex/javaecosystem/capabilities/samples/SamplesTest.java https://github.com/gradlex-org/java-ecosystem-capabilities/tree/main/samples/sample-all Example for 2: https://github.com/CodeIntelligenceTesting/cifuzz-gradle-plugin/blob/main/src/test[…]n/com/code_intelligence/cifuzz/test/fixture/CIFuzzPluginTest.kt https://github.com/CodeIntelligenceTesting/cifuzz-gradle-plugin/tree/main/examples/single-project

thanks everyone!

I also find writing tests for Gradle plugins a real struggle. There doesn’t seem to be a nice way. • Gradle TestKit is great, but lacks some functionality (like setting JVM memory), can be poor performing (too many logs causes OOM), and has some weird bugs (daemons sometimes don’t get killed). • Trying to apply my plugin in test projects can work using TestKit’s `withPluginClasspath()`… but that has flaws, and doesn’t test the plugin-marker. Trying to share my plugin via a local Maven repo is really really not easy. • Using temporary dirs might be recommended, because re-using a directory means the tests aren’t consistent, but often I want to quickly have a look at the test project, and perhaps open it in an IDE, to check why it failed or what assertions I should write. It’s more difficult if it’s in an obscure temp dir. • Personally I prefer writing test projects using raw-strings and using the

@Language

annotation so IntelliJ can help out example, but this isn’t great. It’s often really awkward editing the strings, and I don’t get the full power of auto-complete • Writing gradle.kts fragments and merging them - example - the fragments aren’t loaded in IJ and don’t get auto-complete • Using template projects (standalone examples) can work… but it’s awkward if I want to re-use an example but tweak some of the config • I haven’t dug too much into using includedBuilds, because I keep overthinking it and I don’t want to get into a confusing mess of inter-dependent projects! I’d love for the testing framework to be improved. I’ve been mulling over these ideas: • publishing the DSL I wrote for creating test projects (it’s nice for creating smaller sample project) • helpers for managing copying template projects (Gradle’s sync task is really helpful, especially for find-and-replace, it’d be nice to have that available - can I inject Gradle services in my test classes?) • generate the Kotlin DSL accessors for my plugin (and any others that I may want) that are unscoped and available in my test sources, and create some sort of ‘test project’ DSL that will - so I can fluently create a test project • maybe some sort of specialised kotlin-dsl-test-fixtures source set, which has the

kotlin-dsl

plugin applied so I can write pre-compiled script plugins that would then be built and made available for use in my test projects? • replace

withPluginClasspath()

with a Gradle task that will publish my plugin to a local Maven dir, and then my test-projects can load my plugin from that file-based repo. I made a start on a plugin for this, but it’s kind of buggy.