Check the car's templates and the watch's tile, complication and screens

[octopranav]

The fifth and last stage of the testing drive: the watch and the car.

The car's templates

A car draws an app's screens itself, from templates, and refuses one that breaks its rules. CarScreensTest hands each screen to the Car App Library's own test car (androidx.car.app:app-testing) and reads what comes back, row by row and action by action:

• A saved place: its code, how it is said, how far (from the car's distance span, in whole metres under a kilometre), which way, and the directions to the door.
• Navigate: pressed, and checked for what it hands the driver's navigation app, a geo URI of the place, never the code.
• Where the car is: how close the fix is, and no way to navigate there.
• The list before a fix: newest first, as the shelf keeps it, under where the car is; and a saved place opening its own screen.
• A car with no phone: it says where saved places come from, with the notices in its action strip.
• Search: a code offered as it is typed and opened when sent; a short form waiting for a fix rather than naming a door elsewhere.
• A car older than level 7: the title built the old way.

A deliberately dropped "· directions" on the distance line fails it.

The watch's complication and tile

Each is asked as a watch asks, over a last fix planted in its store.

• Complication:
  • a recent fix shows its short form, said aloud for a screen reader, until its hour is up, then "Find";
  • no fix, or an old one, offers to find one;
  • only short text is offered;
  • the face's picker shows the specification's example.
• Tile:
  • the place for its hour, then the offer to open the app, in one timeline;
  • the first entry ends when the hour does, and the second runs to the end of time, which holds the end-at-zero trap from Give the watch its tile, its complication and its notices #82;
  • drawn by the Tiles renderer the watch itself uses, on a round face at a time held still, and kept as images.

The watch's screens

On a round face with the time held at 10:09: Here asking for location, Here finding, Here with a place, the saved places with their arrows and distances, and walking to one. They are verified in CI beside the phone's (:wear:verifyRoborazziDebug), and repeat exactly when verified twice.

Small seams, each defaulting to the real thing

• CodeTile(clock): the system still gets the no-argument constructor Kotlin writes.
• WatchApp(timeText): the watch's own time unless a test holds it still.
• WatchModel.arrived: now internal, so a test can stand in for the location listener.

Traps found and held

• Robolectric keeps one process across tests. Android's default view-model factory is kept for the process too, so it handed every later watch test the first test's application and its files. The watch's screen tests make their view model with a factory of their own.
• A tile request without a font scale defaults to nought. Every size that follows the reader's text setting came out infinite, and the code and the button's word drew as nothing.
• A library's resources are made only for a build it is part of. The Tiles renderer is in the watch's debug build, never the release; the release guards confirm it, along with no internet and one face.

CI

• Every screen matches its reference image: now :app:verifyRoborazziDebug :wear:verifyRoborazziDebug, keeping the watch's comparisons too when one moves.
• The notices step: runs the car's tests.

Verified

The Android job's checks locally:

• unit tests and screens for the phone and the watch, and the car's tests;
• release bundles;
• the notices checks;
• lint on all seven modules;
• the watch's release guards;
• the benchmarks building.

The phone app's code is unchanged; CI's device job runs its 36 tests.

This completes the drive's five stages: the device suite (#96), the design's reference images (#97), robustness (#98), performance (#99), and this.