Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Is the "Unit" in Unit Testing? Classical vs London School and the Four Pillars of a Good Test
A unit is a behavior, not a method or a class; the classical school, which uses test doubles only at the system boundary, produces tests that resist refactoring better than the London school, which mocks every collaborator. Solitary vs sociable tests, Khorikov's four pillars of a good test, and real output showing how a behavior-preserving change breaks a mocked test.
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.