Wearable test cases, for the workout that never made it back

A wearable is a device that is routinely disconnected from the thing it syncs to, which makes it a distributed system rather than an accessory. Everything recorded while the phone is elsewhere lives only on the watch until it is transferred, and the transfer happens over a transport that drops constantly. That produces the two defects worth building this set around: data that never arrives, and data that arrives twice because the sync retried. Both need stable record identifiers and a resumable transfer, and neither shows up when both devices are sitting on the same desk.

Buffering has a limit and that limit needs a defined behaviour. A device recording for days without a phone will fill its allocation, and silently discarding the oldest readings is the worst available option because the user has no idea it happened. Conflict resolution belongs in the same category: the same activity edited on both devices while disconnected has to resolve by a documented rule, and the user should be asked whenever resolving it would throw away something they typed.

Time is unusually hard here because there are two clocks. A watch that has drifted from the phone will produce timestamps that place a reading before the activity that generated it, and a timezone change mid day will reorder records or move them across a day boundary so the daily totals disagree. Recording the timezone with each entry and reconciling the offset at sync are both cheap, and both are commonly skipped.

Finally, battery is a correctness concern on a wearable rather than a performance nicety. An app that drains the battery by mid afternoon stops recording for the rest of the day, which the user experiences as missing data rather than as poor battery life. The related cases are the low power state, where sampling should reduce rather than stop, and the screen being off, where recording must continue through the intended background mechanism rather than pausing every time the wrist drops.