The SEM Nexus Test Coverage Standard — How We Maintain Real Coverage on Tight Builds

Most agency-built mobile apps ship with somewhere between 0% and 30% test coverage. The number is rarely reported and rarely audited. The founder finds out at month 3 of production, when a regression ships from a routine update and no automated test caught it. The bill arrives in the form of a 3-day production debugging session and a customer-trust hit.

SEM Nexus ships with real test coverage on the critical paths because the discipline is built into the sprint cadence, not bolted on after launch. This post is the standard — what we test, what we don't, and why the math works out at the same cost as a build that ships untested.

What "test coverage" actually means

Not all test coverage is equal. A few distinctions matter:

Code coverage vs. critical-path coverage. Code coverage measures what percentage of lines are executed during tests. Critical-path coverage measures whether the app's most important flows have tests that exercise them end-to-end. The second matters more than the first.

Unit tests vs. integration tests vs. end-to-end tests. Unit tests verify a single function in isolation. Integration tests verify that two or more units work together. End-to-end tests verify a user journey from tap to outcome.

Tests that catch bugs vs. tests that catch regressions. Tests written before the feature ships are designed to verify correctness. Tests written after a bug is fixed are designed to prevent the regression. Both matter; they serve different purposes.

SEM Nexus's target is 80%+ critical-path coverage with a mix of unit, integration, and end-to-end tests. Code coverage typically lands at 60–70%, which is high for agency-built apps in 2026.

What we test (and what we don't)

Always tested:

Authentication flows (sign-up, sign-in, password reset, token refresh)
Payment flows (Stripe, Apple/Google IAP, payout)
Critical state transitions in the data model (job acceptance, dispute resolution, subscription upgrade)
Permission flows (location, push notifications, microphone, camera)
Anything related to compliance (HIPAA, COPPA, GDPR)
Anything that's bitten us in a prior build

Often tested:

UI happy-path flows for the top 5–8 user actions
Integration with each third-party vendor (Stripe, OneSignal, etc.)
Error states and recovery paths
Locale and timezone edge cases

Rarely tested:

One-off internal admin tools used by the founder only
Cosmetic transitions and animations
Visual rendering equivalence across devices (we use device-cloud tools for this instead)

The discipline isn't "test everything." It's "test the things that matter, well."

How the tests get written without exploding the budget

This is where most agencies stall. Tests take time. Tight budgets don't have slack for "extra" testing. SEM Nexus integrates testing into every sprint so it doesn't show up as a separate line item — it's just how features ship.

The rules we apply:

No PR ships without tests for the new code. Test coverage is a merge requirement, enforced by CI.
AI-assisted test generation. Modern AI coding tools generate decent unit tests at 70% accuracy. A senior engineer reviews and corrects. Test writing that used to take 4 hours takes 1 hour with AI.
End-to-end tests written once per critical flow, not per feature. A single E2E test that exercises the booking flow covers 8 features at once. The maintenance cost stays bounded.
Tests for production bugs are mandatory. When a bug ships and gets fixed, a regression test is included in the same PR. Non-negotiable.

The result: test coverage adds about 8–12% to the build effort, not 30–40% as it would on a team that doesn't have the discipline.

Want a build that ships with real test coverage, not a build with "we'll add tests later" promises? SEM Nexus's builds include the testing discipline as a default sprint requirement — not an extra cost.

The tooling stack

Per-stack defaults we use:

Flutter: flutter_test for unit + widget tests, integration_test for end-to-end, Patrol for more complex flows when needed.

React Native: Jest for unit, React Native Testing Library for component, Detox or Maestro for end-to-end.

Angular + Ionic: Jasmine + Karma for unit, Cypress for end-to-end where the app can be exercised in a browser-like context.

Native: XCTest on iOS, JUnit + Espresso on Android.

We don't reinvent. Standard tooling, used consistently.

Why most agencies skip this

Three reasons:

Tests don't sell. A founder pitching tests-as-a-feature is rare. Agencies that compete on price cut tests because the founder didn't ask for them. The cost shows up as production bugs later.

Test maintenance is real work. Tests can become stale, brittle, or wrong. Agencies that don't have a discipline for maintaining tests find them more expensive than helpful. SEM Nexus invests in the maintenance discipline — flaky tests get fixed or removed, not ignored.

Junior engineers struggle to write good tests. Bad tests are worse than no tests because they create false confidence. SEM Nexus uses senior engineers (or seniors reviewing AI-generated tests). The output is reliable.

A real example: My Home Delivery

The My Home Delivery build shipped with:

65% code coverage
~85% critical-path coverage on auth, job state transitions, Stripe Connect payments, location tracking
48 end-to-end tests covering the top 12 user journeys (customer-side and driver-side)
Tests written contemporaneous with features, no "test-debt sprint" at the end

Two years later, the codebase has shipped 100+ updates. The test suite has caught regressions in payments, location handling, and notification routing — bugs that would have shipped to production without the coverage. The founder hasn't been paged for a regression-caused incident in those two years.

That's the value of real test coverage. It's invisible when it works. It would be highly visible if it didn't exist.

What this signals to founders

Three takeaways:

Ask any agency: what's the test coverage on your last shipped build? A real answer is a specific number. Vague answers ("we test what matters") mean the team doesn't measure.

Ask: is testing a separate cost line or built into the sprint? Built-in is right. Separate-line is a signal that testing is optional and likely to get cut under budget pressure.

Ask: who reviews tests for quality? Bad tests are worse than no tests. The answer should involve a senior engineer.

If you'd like a build with real test coverage from day one — not "we'll add tests later" — SEM Nexus's builds include the testing discipline as a default, not an upsell. The coverage shows up in fewer production incidents, fewer 2-AM pages, and fewer "why did this break?" customer escalations. Tests are the cheapest insurance in mobile engineering, and we pay the premium on every build.