Conversation
Reviewing a pull request currently means cloning it and clicking through the sample app by hand to confirm nothing regressed. These two tests do that walk automatically. DemoAppSmokeTest is parameterized over allActivityGroups, the same registry that builds the on-screen demo list, so a demo added to the app is covered with no change to the test. Each demo is launched and checked for three things: it reaches RESUMED, a MapView or StreetViewPanoramaView is attached and laid out, and nothing crashes on a background thread. It then recreates the activity and checks again, which is where camera and marker state holders tend to regress. DemoRegistryTest guards the registry itself. A demo is described both in allActivityGroups and in AndroidManifest.xml; adding it to one and not the other builds cleanly and only fails when someone taps the entry. Map content is deliberately not asserted. Verifying that a particular marker or overlay is drawn belongs in the focused tests alongside these; the value here is breadth.
Coverage (unit tests)No unit baseline recorded in
Line and branch coverage from unit test reports. History is recorded in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Following up on a pull request currently means cloning it, building it, and clicking through every screen of the sample app to confirm nothing regressed. That is slow, easy to skip, and the coverage varies with whoever is reviewing.
What this adds
Two instrumentation tests in
maps-app, both driven offallActivityGroupsinDemo.kt, the single registry that already builds the on-screen demo list. A demo added to the app is covered automatically, with no change to either test. That is the property that makes this worth having rather than another list to keep in sync.DemoAppSmokeTestParameterized over all 22 demos, two checks each:
demoLaunchesAndShowsMap: the activity reachesRESUMED, aMapVieworStreetViewPanoramaViewis attached, visible and non-zero sized, and nothing crashed on a background thread. The map surface is polled rather than checked once, becauseAndroidViewlays it out a frame or more after the activity resumes.demoSurvivesConfigurationChange: the same checks, thenrecreate(), then the same checks again. Configuration changes are where camera and marker state holders tend to regress and are tedious to verify by hand.Map content is deliberately not asserted. Whether a particular marker or overlay is drawn belongs in the focused tests alongside this one; the value here is breadth.
DemoRegistryTestGuards the registry itself. A demo is described in two places that have to agree:
allActivityGroupsandAndroidManifest.xml. Adding it to one and not the other compiles, builds, and only fails when someone taps the entry. Four checks: every demo resolves viaPackageManager, is enabled, has non-blank title and description strings, and is not registered twice.Verification
Run against a Pixel 8 emulator (API 36) with a valid Maps API key:
DemoAppSmokeTestDemoRegistryTest:maps-app:lintDebugAll 22 demos launch, show a map surface, and survive recreation today, so no demo needed an exemption and
DEMOS_WITHOUT_MAP_SURFACEis empty.Cost
DemoAppSmokeTestadds about 2.5 minutes to the emulator job, which currently runs 16 to 28 minutes. If that proves too much for the pull request gate,demoSurvivesConfigurationChangeis the half to move to a nightly run: it roughly doubles the class's runtime and catches the rarer class of bug.Notes
Both tests skip rather than fail when no Maps API key is configured, via
assumeTrue(hasValidApiKey), matching how forks run CI without access to the secret. Worth knowing when reading a green run from a fork: the emulator job injects the key, so skipping only happens where the secret is genuinely unavailable.