[dkhawk]

Description

Stacked PR on top of #1001 (feature/robolectric-tests).

Introduces JVM unit and Compose integration tests using Robolectric and the Android Maps Testing Toolkit (com.google.maps.android:maps-testing-robolectric) for maps-compose-widgets, bringing module line coverage up from 0.00% to 67.12% (instruction coverage from 0.00% to 80.68%).

Summary of Changes

• Added test dependencies (robolectric, mockk, truth, androidx.test.compose.ui, maps.testing.robolectric) in maps-compose-widgets/build.gradle.kts.
• Configured Robolectric Android resources and Java 21 test runner toolchain.
• Added debug manifest with ComponentActivity for Robolectric Compose rule hosting.
• Added ScaleBarTest.kt covering canvas distance calculation, unit conversions (ft, mi), ScaleBar composable rendering, and DisappearingScaleBar camera position animation/state changes.

cc @LoyalAbbas @kikoso

[github-actions]

Coverage (unit tests)

Compared against 889c2dc on feature/robolectric-tests (#1047).

Module	Line %	Change	Branch %	Change
maps-compose	40.75%	🔺 +25.48	12.54%	🔺 +8.78
maps-compose-utils	26.29%	no change	12.70%	no change
maps-compose-widgets	70.07%	🔺 +59.19	58.33%	🔺 +47.22
TOTAL	38.71%	🔺 +20.96	13.95%	🔺 +8.12

_{Line and branch coverage from unit test reports. History is recorded on the coverage-history branch after each merge to feature/robolectric-tests.}

[googlemaps-bot]

Code Coverage

Overall Project	44.45%	🍏

There is no coverage information present for the Files changed

[kikoso]

Minor comments @dkhawk , but looks good! The instrumentation failure is the emulator not starting in maps-app (adb could not connect), unrelated to this PR, so a rerun should do.

[kikoso]

This repeats the same formula as calculateDistance, so if someone changes the ratio by mistake the test still passes. What about asserting against a known value instead? 0.001° of longitude at the equator is roughly 111 m, so we would expect around 98.

[kikoso]

Could we assert something here? Right now the test passes as long as nothing crashes. Setting composeTestRule.mainClock.autoAdvance = false and advancing past visibilityDurationMillis would let us check that the bar shows after the camera change and hides again, which is the actual behaviour of this composable.

[kikoso]

nit: ScaleBar.kt uses com.google.maps.android.sphericalDistance. Should we use the same one here so the test and the production code stay on the same implementation?

Suggested change

	import io.mockk.every
	import com.google.maps.android.sphericalDistance