"Developers should own quality." Every engineering leader says this. Few actually make it work. The problem is rarely motivation. It's infrastructure. If writing a test takes longer than writing the feature, developers will skip it every time.
Why developers don't write tests
I've asked dozens of developers this question. The answers are always the same:
- "Tests are slow to run." If running the test suite takes 20 minutes locally, nobody runs it before committing.
- "I don't know how to test this." Complex setups, mocking, and test infrastructure aren't skills every developer has.
- "The existing tests are a mess." If the test suite is flaky and unmaintained, adding to it feels pointless.
- "There's no time." Sprint pressure prioritizes features over tests. Without explicit time allocation, tests lose.
Notice: none of these are "I don't care about quality." Every developer wants to ship reliable code. They need the system to make it easy.
Build the infrastructure first
1. Make tests run in under 30 seconds locally
If a developer can write a test and see results in 30 seconds, they'll write tests. If it takes 5 minutes, they won't. Invest in:
- Fast unit test runner (Vitest over Jest for most projects)
- Selective test execution (only run tests related to changed files)
- In-memory databases for integration tests
2. Provide templates and examples
Create a /tests/examples directory with templates for every common pattern: API endpoint test, component test, E2E flow test, database query test. Developers copy-paste and modify. Friction drops to near zero.
3. Make CI enforce it
Add a coverage threshold to CI. Not 100% (that's counterproductive), but enough that skipping tests is harder than writing them. Start with 60% for new code and increase gradually. Block PRs that drop coverage below the threshold.
4. Include tests in the definition of done
Code review should include test review. If a PR adds a feature without tests, it's not done. This isn't about bureaucracy. It's about treating tests as part of the deliverable, not an afterthought.
The developer-friendly testing stack
A stack that developers actually use:
- Unit tests: Vitest (fast, modern, great DX)
- Component tests: Testing Library (framework-agnostic, tests behavior not implementation)
- API tests: Supertest or Playwright API testing (simple HTTP assertions)
- E2E tests: Playwright (codegen to generate boilerplate, then refine)
- CI: GitHub Actions with test result comments on PRs
The role of a QA engineer in this model
When developers own testing, the QA engineer's role shifts from writing tests to building the system that makes testing easy:
- Setting up test infrastructure and CI pipelines
- Creating test utilities, fixtures, and helpers
- Reviewing test quality in code reviews
- Identifying coverage gaps and risk areas
- Running exploratory testing for edge cases automation can't catch
One QA engineer building infrastructure is worth more than three QA engineers writing tests manually.
Measuring success
Track these metrics to know if it's working:
- Test coverage trend: Should increase month over month without mandating 100%
- PR test inclusion rate: Percentage of PRs that include tests (target: 80%+)
- Time from commit to test result: Should be under 10 minutes in CI
- Production bug rate: Should decrease as coverage increases
Want to build a testing culture where developers own quality? Get in touch. We set up the infrastructure, templates, and CI that make it happen.