Write most security tests as fast unit and integration tests, and keep slow end to end tests for a few critical journeys. The test pyramid gives the shape: many tests at the bottom, fewer above. Pushing a security check down the pyramid makes it cheaper to run on every change, which is what makes it actually run.
The pyramid in brief
Martin Fowler's practical test pyramid article, building on Mike Cohn's idea, groups tests by granularity. Many fast unit tests sit at the base, fewer coarse tests above, and very few end to end tests at the top. A suite that inverts this, with lots of slow browser tests and few unit tests, is called an ice cream cone, and the author treats it as an anti pattern.
The article's advice on duplication is useful here: push each test as far down as it can go, and let higher tests cover only what lower ones cannot.
Security checks by level
Unit tests. Fast and numerous. Good for:
- Input validation rules: lengths, formats, rejected characters.
- Authorization decisions for a single function, such as whether a role may perform an action.
- Output encoding and escaping helpers.
- Token and session handling logic, including expiry.
The article advises testing observable behavior, not internal structure, so refactoring does not break tests.
Integration tests. Cover one integration point at a time, such as the database or an external API. Security uses:
- Queries are parameterized and hostile input does not change their meaning.
- A database account has only the permissions it should.
- Files are stored where and how you expect.
Run dependencies locally or use test doubles. Fowler is direct that automated tests should avoid integrating with the real production system.
Contract tests. Consumer driven contracts let teams define what they expect from a service and have the provider verify it. For security, a contract can state that an endpoint requires authentication or returns specific error shapes, so a change to the provider that drops a check breaks a test.
End to end tests. Slow, flaky and expensive to maintain, according to the same article. Reserve them for the most valuable journeys. A login, a password reset and a payment are fair candidates, since a regression there is serious.
Exploratory testing. Manual, creative testing finds what automation misses. A short, time boxed session aimed at abuse cases, run before a major release, is worth the hour. Turn what you find into automated tests where you can.
A worked placement
Rule: users may only view their own invoices.
- Unit test: the policy function denies a different user's identifier.
- Integration test: the invoice query includes the owner condition.
- Contract test: the invoice endpoint rejects unauthenticated requests.
- End to end test: one journey where user A tries to open user B's invoice and is refused.
The unit test catches most regressions in milliseconds. The end to end test is the safety net.
Order your pipeline by speed
Fowler recommends ordering pipeline stages by speed and scope to give fast feedback, not by test type. Put unit and policy tests first, integration next, slow tests last. Static analysis and dependency checks run in parallel at the start.
Test code is code
The article says test code is as important as production code. Review it, keep it readable, and delete tests that duplicate lower level coverage. A suite nobody trusts gets ignored.
Safeguard adds dependency and SBOM scanning, plus zero day discovery, which unit tests cannot supply. The free scan is at gold.safeguard.sh/scan.
Quick check
Should security tests be a separate suite?
Not usually. Place each at the lowest level that can catch the issue, and run it with the normal suite so it runs on every change.
Are end to end tests useless for security?
No. Keep a few for critical journeys such as login and access control, and avoid relying on them for broad coverage.
Sources
Last reviewed: 19 October 2026.
