This message was deleted.
# community-support
s
This message was deleted.
t
@Julio Cesar Bueno Cotta Hi đź‘‹ You can try to create
test/
source set under the module where you are hosting the convention plugin. In the test you need recreate Android project structure in some temporary dir. Here is an example from gradle-play-publisher.
j
Ok, thank you Tom! It will help a lot.
👍 1
b
One of the Gradle samples with a
buildSrc
showed how to test a plugin, I sort of recall seeing a unit test class simulating adding a project folder and seeing spotless fail, I'll try to dig it up
There we go: https://docs.gradle.org/current/samples/sample_convention_plugins.html Inside the sample zip there're tests in
buildSrc/src/test/kotlin/com/example/
It references TestKit, which might also be a good read
❤️ 2
j
if I understand it correctly, I could have a "sample" project that I could reference the
projectDir
in my tests and assert in the results of a task like "assembleDebug"
t
It is more about creating “sample” project that follows the Android project structure, then you apply your plugin within this “sample” project and then you call “assembleDebug” task with the help of
GradleRunner
. In the sample shared by Ben you can find the
PluginTest
class that creates files for the project and the exposes
runTask
program. So in you case you need to create
Copy code
settings.gradle
build.gradle
src/main/AndroidManifest.xml
local.properties
It is important to have path to SDK in
local.properties
Copy code
// root is a tmp folder generated for test
root.resolve("local.properties").writeText("""sdk.dir=${System.getenv()["ANDROID_HOME"]}""")
if not set you won’t be able to call
assembleDebug
.
j
I noticed that. Now I need to learn how to assert stuff like "the targetSdk is API 33 for that build", "proguard was enabled" and stuff like that...
b
Yeah I don't know enough about TestKit to help at that level unfortunately If I had to guesstimate, I'd maybe suggest looking at something like: https://docs.gradle.org/current/userguide/test_kit.html#example_using_gradlerunner_with_groovy_and_spock So defining a task to be run which checks for the
targetSdk
, or checking that Proguard is enabled, etc.
j
ok, got it. Thanks
t
There is another approach you can test the side effects of your plugin. It is different from having temp repo and then GradleRunner executing it. You can create an instance of the
Project
apply plugin and then with the help of
android
extension access the property your are modifying to assert that the specific variant has API set and minify enabled. Here is an example of how to create
Project
instance and then apply plugin to it directly. https://github.com/KeepSafe/dexcount-gradle-plugin/blob/362bcf369aabc2c937491488f4[…]st/groovy/com/getkeepsafe/dexcount/DexCountExtensionSpec.groovy