Testability and Shift-Left Testing Questions

I’d treat this like a reproducibility and isolation problem first, not a test-writing problem.

My steps would be:

1. Re-run the exact CI artifact locally if possible: same commit, same build type, same simulator/emulator image, same locale and device size.
2. Collect evidence: logs, screenshots/video, test order, network activity, and whether failures correlate with timing or a specific screen.
3. Narrow the scope: run the failing test alone, then with nearby tests, then in the full suite to see if there is shared state leakage.
4. Check common mobile causes: animations not disabled, missing synchronization, stale app state, async work still running, resource contention, or dependence on previous tests.
5. Fix the root cause by making the test deterministic: better selectors, explicit waits on app state, hermetic test data, reset between tests, and stable test fixtures.

I would only use retries as a temporary shield, not a fix. If a test is still flaky after that, I’d quarantine it short-term, keep the behavior covered elsewhere, and assign ownership until the underlying issue is resolved.

Code coverage is useful, but it only tells you that code was executed, not that it was meaningfully verified.

A high number can be misleading when tests:

• execute lines without asserting important outcomes,
• miss edge cases and error paths,
• rely on mocks so heavily that nothing real is exercised,
• or leave critical user flows untested while chasing percentage points.

Meaningful coverage asks, "Are we protecting the product?" I look at:

• branch and path coverage on risky logic,
• tests around recent bug fixes and churn-heavy code,
• mutation testing or at least hand-checking assertion strength,
• escaped defects and flaky-test trends,
• and whether critical user journeys have at least one solid test at the right layer.

For example, a screen can have 95% line coverage and still fail on a null API field or a background/foreground transition. I’d rather have slightly lower coverage with strong assertions on the risky paths than a high percentage that gives false confidence.

Situation: On a mobile team I joined, we had a lot of regressions in one feature area because the view models were doing too much and our tests were mostly high-level UI tests.

Task: I wanted to improve both code quality and test quality so bugs were caught earlier, without slowing delivery.

Action: I extracted network and persistence logic behind small protocols, moved parsing into a pure mapper layer, and added focused unit tests around the business rules. I also replaced several brittle UI assertions with a smaller number of end-to-end checks that verified the full flow. To keep the team aligned, I added test-review guidance in PRs: if logic could be tested without UIKit/Android UI, it should be.

Result: The feature became much easier to change, and we started catching bad payload handling and state bugs in unit tests instead of in QA or CI. I knew it helped because flaky UI failures went down, PR reviews got simpler, and the same area produced fewer escaped defects after the refactor.

The main lesson for me was that quality improves fastest when tests match the right layer of the architecture.

I’d make the standards explicit, automated, and incremental.

First, I’d agree as a team on a small set of rules that actually matter: things like no unchecked force unwraps, no obvious thread-safety hazards, no dead code, and no new lint violations in touched files. Then I’d encode as much as possible in tooling so reviewers aren’t the enforcement mechanism.

Practically, that means:

• fast local lint and formatter hooks,
• static-analysis checks in CI,
• a clear severity policy: block on correctness issues, warn on style issues,
• and a review checklist that focuses humans on architecture, naming, and risky trade-offs.

I’d also avoid creating a bottleneck by ratcheting gradually. Don’t fail the whole codebase on legacy warnings; prevent new debt from entering and chip away at old debt over time. If a rule is too noisy, tune or remove it. That keeps trust high.

The goal is consistency and bug prevention, not gatekeeping. Good standards should make reviews shorter, not longer.

I avoid arbitrary sleeps because they make tests slow and nondeterministic. Instead, I try to control the source of asynchrony.

Patterns I use:

• Expectations or latches: wait for a specific callback or event, with a timeout only as a safety net.
• Fake clocks or test schedulers: for timers, debounce logic, or reactive streams, I advance virtual time manually instead of waiting in real time.
• Injected executors/dispatchers: run work on a test-controlled thread or immediate executor.
• Async/await or promise testing: await the final state rather than polling.
• For streams, subscribe in the test, emit events explicitly, and assert the sequence.

The key is to make the async dependency injectable so the test controls when work happens. That keeps tests fast, repeatable, and easy to debug. If a test still needs a timeout, I keep it short and use it only to fail fast, not to "solve" synchronization. The best async tests are ones where the test owns time and input, not the app.