i am trying to create (register) a gradle task that modifies the configuration, but I only want this...

# gradle

[Kris Wong]

i am trying to create (register) a gradle task that modifies the configuration, but I only want this to happen when the task itself is executed. how can I achieve this?

android.defaultConfig.testInstrumentationRunnerArguments.remove 'notClass'
        android.defaultConfig.testInstrumentationRunnerArguments 'class': 'com.boxer.sendHarness.SendMessageHarness'

[trevjones]

because the notClass is going to be a part of the original task inputs you really shouldn't change it after the configuration phase. (agp in particular generates a ton of new models and tasks at the end of configuration so many times late changes don't work anyway) If the instrumentation runner args are backed by a gradle Property<T> you could replace it with a new one that is the output of a task which might give you lazy enough eval to do it without breaking the gradle input/output tracking system.

[Kris Wong]

hmmm. I might want to find a different way to do this

[Kris Wong]

maybe I'll just have the task execute the instrumentation directly

[trevjones]

just trying to do a basic "run androidTest with these args"?

[Kris Wong]

i want a gradle task that executes one specific instrumented test, which is normally not executed

[trevjones]

what about doing an additional invocation with an added cli argument for the runner argument?

[Kris Wong]

the default configuration disables the class, so I need to invoke the instrumentation directly

[trevjones]

right but what i mean is:

./gradlew app:testVariantAndroidTest
./gradlew app:testVariantAndroidTest -PinstArgs="foo,bar"

[trevjones]

nearly everything on the second round would be up-to-date

[Kris Wong]

ah, I see what you mean

[trevjones]

agp might already have a way to do that as well

[trevjones]

not sure off the top of my head though

[Kris Wong]

yeah was hoping for a self contained gradle task, but not a big deal to use a project property instead

[trevjones]

there is also the com.android.test plugin to make additional test packages. maybe that could be useful

[trevjones]

split up your suites to different modules or something like that

[Kris Wong]

hmmm

[Kris Wong]

will check that out. thanks!