Testability and Shift-Left Testing Questions

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.

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.

I would split the screen or view model into pure logic and side effects.

First, I’d inject dependencies instead of constructing them: an API client interface, a parser/mapper, and a repository or persistence gateway. The view model should orchestrate state, not know how HTTP or storage works.

A good shape is:

• ViewModel: handles user intent and UI state.
• Use case or service: contains business rules.
• Repository: coordinates remote and local data.
• Data sources: one for API, one for storage.
• Mapper: converts raw DTOs into domain models.

That gives you unit-testable seams. You can test the view model with fake dependencies, verify it emits the right state, and test the repository separately with stubbed API responses or an in-memory store. Parsing should happen in a pure function or mapper, so malformed payload handling can be tested without UI or storage.

This design reduces coupling, makes failures easier to localize, and prevents a single class from becoming impossible to test.

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.

I usually separate the problem into two concerns: network I/O and persistence.

For network calls, I prefer a stub or fake server over a pure mock when I want realistic request/response behavior. In iOS that often means abstracting the client behind a protocol and stubbing the transport; in Android/Jest-style tests, I’ll use a fake repository or a local test server. For persistence, an in-memory database or fake store is usually better than mocking every DAO method, because it exercises real reads, writes, and queries.

Trade-offs:

• Mocks: best for verifying interactions, but they can make tests brittle if you over-specify call order.
• Stubs: good for fixed responses and deterministic tests, but they don’t model state changes.
• Fakes: great for higher-confidence tests because they behave like a simplified real dependency, but they take more effort to build.

My rule is: use mocks sparingly for collaboration boundaries, use stubs for simple branching, and use fakes or in-memory implementations when the behavior itself matters. That keeps tests fast, readable, and closer to production behavior.