Three kinds of evidence
A passing build proves compilation, not conversation quality. A deterministic test proves a specified behavior under controlled inputs, not provider availability. A successful live answer proves an observation for one model, account, and device, not that every prompt is safe or correct.
The pinned app recorded 19 unit tests and five emulator tests for the preceding core-chat build; the branding update added unit checks without rerunning the device suite. Be precise about that history. Your learning branch adds three context-policy tests and may add a directory test. Record your actual total rather than copying a badge.
Test the boundaries independently
./gradlew :app:testDebugUnitTest :app:lintDebug
./gradlew :app:connectedDebugAndroidTest
./gradlew :app:assembleRelease
Use an isolated emulator for instrumentation. Some test runners uninstall their installation. Avoid simultaneously running tests and typing a personal live conversation into the same package.
The repository's fake service tests history, duplicate prevention, and Stop. MockWebServer checks SSE/HTTP behavior and cancellation of the underlying call. Room and Activity tests exercise Android-specific integration. Keep those responsibilities separate so a failure points to a meaningful boundary.
A small live evaluation set
| Prompt or action | Evidence to record |
|---|---|
| Explain a Kotlin concept | Correctness, clarity, uncertainty where appropriate |
| Follow up on a prior constraint | Context retained without importing another chat |
| Stop a long answer | Partial text labeled stopped; no later append |
| Ask for a codelab | Relevant known resource, no invented route |
| Ask for current mentorship price/slots | Direct to current website, no unsupported promise |
| Background and return | Key cleared, no silent request restart |
Time first visible text and final completion only if you record device, model, network conditions, and how the timestamps were obtained. Do not publish a universal latency claim from one run. Quota tests should be simulated rather than deliberately exhausting real quota.
Release is a different boundary
The debug adapter lives in a debug source set; release has an unavailable service. An authenticated backend must own provider credentials, authenticate/authorize requests, apply quotas, and propagate cancellation. A release APK that compiles is not evidence that those services exist.
Check your understanding
How would you demonstrate the claim “Stop works”? Show a UI result, a canceled HTTP call in a deterministic test, and a live observation where possible. Explain that closing a connection alone does not guarantee the provider stopped generation or billing immediately.