Testability and Shift-Left Testing Questions

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’d design the pipeline in layers so fast feedback happens on every pull request, while deeper confidence is built before release.

PR pipeline:

• format/lint/static analysis,
• unit tests,
• a small set of deterministic integration tests,
• and a build artifact that can be reused downstream.

Pre-release pipeline:

• broader integration and UI coverage,
• device or simulator matrix for the supported OS versions,
• accessibility and release-specific checks,
• and signing/package validation.

To keep it reliable, I’d build once and test many times, cache dependencies, parallelize by test group, and keep the environment as deterministic as possible. Flaky tests need ownership, not silent retries forever. If a test is unstable, quarantine it temporarily and fix the root cause.

I’d also monitor pipeline health: duration, failure reasons, rerun rate, and the percentage of failures caused by the test system versus the product. Engineers trust CI when it is fast, predictable, and clearly signals what actually broke.

I’d test accessibility at three levels: semantic checks, interaction checks, and real screen-reader verification.

What I can automate:

• Every interactive element has a meaningful label, hint, or content description.
• Focusable elements are exposed in a sensible order.
• Buttons and controls have the right traits and are large enough to tap.
• State changes are announced or at least reflected in accessible text.
• Accessibility scanners can catch obvious issues like missing labels or low-contrast text.

What still needs manual review:

• Whether VoiceOver or TalkBack reads the screen naturally.
• Whether the focus order matches the visual and task flow.
• Whether dynamic updates, modal dialogs, and errors are announced at the right time.
• Whether the feature is usable with only the screen reader, no sighted assistance.

I’d build the automated checks into CI and include accessibility in the definition of done, but I’d still do at least one manual pass on a real device before release. Automation finds regressions; humans catch usability problems.

Unit tests, integration tests, and end-to-end tests each protect a different risk.

• Unit tests: verify one class or function in isolation. They are fast, precise, and best for business rules, edge cases, and pure logic.
• Integration tests: verify that components work together, like a repository talking to a database or a view model calling a service. They catch wiring and contract issues.
• End-to-end tests: simulate the user journey through the app UI. They are slower, but they protect the most important flows from a real-user perspective.

If I were starting a feature from scratch, I’d put most logic in unit-testable code, add integration tests at the boundaries that are likely to break, and reserve end-to-end tests for critical paths like sign-in, checkout, or data submission. That gives good coverage without making the suite too slow or brittle.

My rule is simple: test the behavior at the lowest layer that can prove it correctly, and only go higher when the user experience itself is the thing at risk.