Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Code Coverage Tells You and What It Doesn't: Line, Branch Coverage and Mutation Testing
Code coverage only tells you which code ran, not whether the tests verify anything: a test without a single assertion gave 87.5 percent line and 100 percent branch coverage, while its Stryker.NET mutation score was 6.67 percent. The MTP coverage extension, ReportGenerator and coverage in Angular, surviving mutants that expose boundary values, mutation testing only changed code with --since, and coverage threshold traps.
What to Test at Which Level: Behavior, Boundaries and Which Dependencies to Mock
Domain logic gets heavy unit testing, orchestration code a few integration tests; trivial code goes untested and overcomplicated code is refactored first. In tests your own database (managed) is real, while unmanaged dependencies such as payment and email are mocked. The real output of a mock-heavy test breaking on a behavior-preserving refactoring, risk-based prioritization and a one-page test strategy document.
Test Pyramid, Testing Trophy and Honeycomb: Which Shape Fits Which System?
The right shape depends on which test level gives confidence most cheaply in your system: a domain-heavy API suits the pyramid, a thin CRUD API and an Angular SPA suit the trophy, and microservices suit the honeycomb with contract tests. A search query that passes on the InMemory provider but returns 500 on real SQLite, a type error the static layer catches in 0.8 seconds, and the ice-cream cone and hourglass traps.
Why We Write Tests: Unit, Integration, Contract, E2E, Smoke and Other Test Types
The real return on tests is confidence against regressions, speed of change and living documentation; the price is writing, maintenance, duration and flakiness. We separate test types by scope (unit, component, integration, contract, E2E) and by purpose (smoke, regression, acceptance, exploratory), and show with six real Bookstore tests and measured durations that Google's small/medium/large classification is independent of scope.
OWASP API Security Top 10: What Changed from 2019 to 2023 and Reading Old Reports in Today's Terms
In the 2023 edition Excessive Data Exposure and Mass Assignment merged into BOPLA, API2, API4 and API9 were renamed, Injection and Logging left the list, and sensitive business flows, SSRF and unsafe consumption were added; so old findings are mapped by meaning, not by number. A mapping table, a small tool that translates old reports and shows unassessed categories, and what we'll do when a new edition arrives.
Continuously Testing and Monitoring API Security: Authorization Regression, OpenAPI-Driven Scanning and Abuse Telemetry
To keep API security in place continuously, you put the controls into a test pyramid, run an OpenAPI-driven scanner only against your own environment and turn its findings into regression tests, and measure rejected requests per tenant. Contract gaps and two 500s found by Schemathesis, a systematic fix with RespectNullableAnnotations, OpenTelemetry metrics and a one-page checklist.
API8 and API9: Misconfiguration and Inventory — Using OpenAPI as an Inventory, Deprecation/Sunset Headers and Shadow APIs
Against API8 you tie an API-specific checklist to tests that run in the Production environment; against API9 you use the OpenAPI document generated at build time as a committed inventory and retire old versions with the RFC 9745 Deprecation and RFC 8594 Sunset headers. CORS and middleware order, catching an unannounced endpoint with git diff, and a time zone trap.
API7 and API10: APIs That Talk to the Outside World — Webhooks, Outbound URL Validation and Not Trusting Third-Party Responses
You validate a user-supplied webhook URL by shape at registration and, at connect time, on every resolved address with SocketsHttpHandler.ConnectCallback, and you treat third-party responses like user input. A DNS rebinding imitation, delivery without redirects, a signed payment webhook processed once, and a shipping API response validated with a size limit and resilience.
API6 Sensitive Business Flows: Identifying Sensitive Flows, Idempotency-Key and Flow-Level Limits
Against API6 you first identify which business flows automation can damage, then give each flow its own rule. A filter that processes repeated POSTs once following the Idempotency-Key draft, a concurrent retry test, enforcing coupon and limited-item rules with database constraints and a conditional UPDATE, RFC 9470-style step-up, and a per-customer flow limit.
API5 BFLA: Automated Authorization Tests from the Endpoint Inventory and Separating Admin APIs
You close BFLA for good with tests that list the endpoints the application really exposes through EndpointDataSource and verify that each one carries an explicit authorization decision and has rows in the matrix. We separate the admin surface with a route group, a policy and its own port, show that RequireHost can be bypassed with the Host header and add a real port check, and handle per-method permissions and method override headers.
API4 Unrestricted Resource Consumption: Page Size, Query Complexity, Timeouts, Quotas and Costly External Calls
Against API4 you put an upper bound on every parameter, every endpoint and every external call that costs money, and guard it with tests. Starting from an unbounded list measured with 200,000 orders, we build page size, offset and sort allowlists, bulk and body limits, request timeouts with CancellationToken, and tenant- and plan-based report and SMS quotas with 429 and Retry-After.
API3 BOPLA: Property-Level Authorization, PATCH Requests and Response Shaping
You close BOPLA not with serializer settings but with a separate response type per role and a writable-field allowlist per role. Projections with Mapperly that break the build when a field is added, moving a different view to its own endpoint and policy, rejecting locked fields in JSON Merge Patch, and using the OpenAPI schema as a contract guarded by a test.