Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    A Testing Strategy Teams Actually Adopted

    Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.

    Growingcase studytended planted 2 min read
    On this page

    Context

    At Sky I worked across several React front ends for network automation tooling. Testing was uneven: some services had decent unit tests, many had very few, and end-to-end testing was mostly manual. The team had a coverage goal on paper.

    Problem

    Coverage goals on their own produce bad tests. The quickest way to hit a number is to mock every module and assert on implementation details, which gives you tests that break on every refactor and catch very little. Separately, slow quality checks in CI meant developers waited a long time for feedback, and end-to-end tests were blocked by corporate single sign-on.

    What I did

    • Mocked the network, not the code. I introduced MSW handlers into the test setup, so tests exercised the real data layer against realistic API responses (Stop Mocking Fetch). Writing tests got quicker, and they survived refactors.
    • Refactored services towards testability. Pure logic moved into plain functions with unit tests; hooks and pages got integration tests. This is the strategy in React Testing Strategy.
    • Got a free offline mode. The same handlers ran in the browser, so the app could run locally against mocks. Demos and development stopped depending on a shared environment being up.
    • Shipped new features test-first. On a new component library, the first end-user feature was written tests-first (unit, integration and stories) and became the pattern the team copied (Storybook).
    • Made quality visible and fast. I optimised the lint job so it ran several times faster, and added per-line and overall coverage indicators to every merge request, so reviewers could see untested lines immediately.
    • Championed Playwright across departments. I worked through the authentication problem (test users and test-friendly auth policies in non-production environments), and set up mocked-state suites that ran in pipelines and doubled as stable environments for demos and user acceptance testing (Playwright).

    Outcome

    Coverage on the services I focused on rose substantially, with tests that were meaningful rather than brittle. Playwright was adopted for end-to-end testing across departments, as the CV says, and AI tooling helped extend unit-test coverage across projects. Feedback in merge requests got faster and more informative.

    What I’d do again

    • Pick the mocking boundary first. Everything else follows from mocking at the network.
    • Make the right thing visible. Coverage shown in every merge request changed behaviour more than any coverage target did.
    • Solve the boring blocker. For end-to-end tests the blocker wasn’t the framework, it was authentication. Fixing that unlocked everything.

    What I’d do differently

    Add contract checks earlier. Mocks drift from the real API, and a few consumer-driven contract tests would have caught mismatches before integration did.

    Shift Left Testing · Removing Secrets from Git History · Building a Graph Component Library

    • #testing
    • #msw
    • #playwright
    • #ci
    • #coverage
    • #case-study

    ↪ Links to (8)