Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
The xUnit Test Lifecycle: Constructors, IAsyncLifetime, Fixtures and Full Parallelism in 4.0
xUnit creates a new instance of the test class for every test; expensive, read-only setup is done once in a class, collection or assembly fixture. In 4.0, ParallelMode.All cut an 8-test example from 1.06 to 0.55 seconds, but two tests sharing a static fake failed in 16 of 20 runs. IAsyncLifetime, opt-out levels, ITestOutputHelper and TestContext attachments.
Data-Driven Tests in xUnit v3: Theory, MemberData, TheoryData, TheoryDataRow and MatrixTheoryData
In data-driven tests, which rows you pick matters more than how many: boundary values and equivalence partitioning caught Math.Round's banker's rounding with two rows. In xUnit v3: InlineData, MemberData and type-safe TheoryData, TheoryDataRow with per-row display name, label, trait and skip, MatrixTheoryData, dynamic skip, Explicit tests, and how non-serializable data affects Test Explorer.
Anatomy of a Good Unit Test: AAA, Naming, One Behavior and Readable Assertions
A good unit test runs one behavior through a single Act, contains no branching, and when it turns red its name and failure message explain the problem without opening the code. The limits of AAA, Method_Scenario_Expected vs plain-sentence naming, Assert.Multiple, and Shouldly, AwesomeAssertions and FluentAssertions 8's Xceed license, with real failure messages.
A Test Project with xUnit v3: Microsoft Testing Platform, dotnet test and First Tests
An xUnit.net v3 test project is an executable and, since 4.0, runs on Microsoft Testing Platform v2 by default; once global.json sets the test runner on the .NET 10 SDK, dotnet test rejects VSTest projects. The xunit3 template, the package chain, dotnet test vs dotnet run, Assert.Throws/ThrowsAsync, TestContext.Current.CancellationToken and xUnit1051, filters, TRX reports and exit code 8.
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.