Skip to content

Conversation

@rharter
Copy link
Collaborator

@rharter rharter commented Dec 6, 2024

This is a proof of concept implementation to explore the changes discussed in issue #31 (this comment specifically) to allow support for writing reference and diff images to the additional_test_output directory and leverage the AGP DeviceProvider to accessing devices.

This is a fairly substantial change, so I'm creating a draft for feedback. There are several user-facing changes, most importantly the reference screenshot directory structure changes from src/androidTest/screenshots to src/androidTest/screenshots/connected for the existing tests that are supported, and src/androidTest/screenshots/{device_name} for any additional devices (not validated yet).

So far this change is tested with connected tests, with the intention that this will support Gradle managed devices, but I'm still testing and validating that. I wanted to share this draft for feedback and testing before it gets too big.

There are still some unknowns with this approach. For instance, DeviceProvider is deprecated, but it's unclear what the accessible replacement is. I also don't love the way that TestRunConfig is written to the device and would prefer to be able to add instrumentation arguments to the text execution instead, for reading at runtime.

.named {
it == "${deviceProviderName}${variant.name.capitalize()}${ComponentType.ANDROID_TEST_SUFFIX}"
}
.all { testTask ->
Copy link
Contributor

Choose a reason for hiding this comment

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

should be configureEach to avoid task creation

else -> return@all
}
val defaultTestOutputDirectory = layout.buildDirectory
.dir("outputs/androidTest-results/$deviceProviderName/${variant.name}")
Copy link
Contributor

Choose a reason for hiding this comment

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

I was having trouble figuring our additionalTestOutputDir and I don't think it's actually used because of the return in testDataProvider evaluation above.

I think collpasing additionalTestOutputEnabled and additionalTestOutputDir would be a lot more readable.

val additionalTestOutputDir = when (testTask) {
    is DeviceProviderInstrumentTestTask -> testTask.additionalTestOutputEnabled.flatMap {
        if(it) { testTask.additionalTestOutputDir } else { provider { null } }
    }
    is ManagedDeviceInstrumentationTestTask -> testTask.getAdditionalTestOutputEnabled().flatMap {
        if(it) { testTask.getAdditionalTestOutputDir() } else { provider { null } }
    }
    is ManagedDeviceTestTask -> testTask.getAdditionalTestOutputEnabled().flatMap {
        if(it) { testTask.getAdditionalTestOutputDir() } else { provider { null } }
    }
    else -> return@configureEach
}

I would also consider combining it with the testDataProvider so that you only have a single when to read, but you'd need a data class of a pair return type so it's a little more subjective.

public abstract class DeviceProviderFactory {
@Suppress("DEPRECATION")
@get:Internal
internal var deviceProvider: DeviceProvider? = null
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this assigned anywhere? What's the reason for using a Nested Bean instead of just some helper method for getDeviceProvider?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is modeled after AGP, and I left this as a provider to enable tests that don't require connecting to actual devices. Those tests aren't implemented, and may not be, but I left this to leave that possibility.

@JoseAlcerreca
Copy link
Contributor

Just a heads-up; additional test output might be broken when using multiple devices https://issuetracker.google.com/389673587

It'd be great if you could confirm this issue.

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.

4 participants