Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Choosing and Combining Techniques: From Requirements to a Test List, Aligning with Acceptance Criteria and the Limits of AI-Generated Test Cases
The shape of the requirement picks the technique: equivalence partitioning and boundary value analysis for ranges, decision tables for combinations of conditions, state transitions for outcomes that depend on history; combined and deduplicated, they leave one test list. For Bookstore's institutional partial shipment story, five techniques produced 27 conditions, the list came down to 19, and the row where three techniques met caught the bug. A prompt and review checklist for AI test cases.
White-Box and Experience-Based Techniques: Using Branch Coverage for Test Design, Error Guessing, Checklists and Exploratory Testing
In test design, a branch coverage report isn't a target but a tool that points at branches that never ran and yields new test cases; it can't see code that was never written, which error guessing, checklists and exploratory testing find. For Bookstore's coupons, the report found a bug in a cap branch missing from the story, error guessing found the Turkish I bug, and an exploratory session found duplicate orders from double clicks and a negative total; all became regression tests.
Combinatorial Testing: Managing Configuration Explosion with Pairwise, Orthogonal Arrays and PICT
Pairwise testing cuts the cost of every-combination testing by putting every value pair of any two parameters side by side in at least one test; it rests on the assumption that most bugs come from one parameter or the interaction of two. In Bookstore's checkout, each choice's three tests missed the missing English store pickup template; the 11 rows PICT generated from a constrained model caught it. t-wise, orthogonal arrays, seeds, oracles and Playwright projects.
State Transition Testing: Deriving Test Cases from the Order State Machine, Invalid Transitions and 0-Switch/1-Switch Coverage
State transition testing derives test cases from the state diagram and the state table when a system's behavior depends on its history: valid transitions (0-switch), invalid transitions in the table's empty cells, and pairs of consecutive transitions (1-switch). For Bookstore's order, three green tests missed that a shipped order could be cancelled and that an order released from a hold couldn't be shipped; 40 invalid transitions and 10 transition pairs caught both.
Decision Table Testing: Rule Combinations, Collapsing the Table and From Rule Table to Tests
Decision table testing lays out every combination for rules whose outcome depends on several conditions, collapses the table and turns each column into a test. For Bookstore's shipping fee, four green tests written one per sentence missed the contradiction in a Plus member's international shipping and seven undefined coupon cases; the table showed them all before any test was written. Limited and extended-entry tables, "–" and N/A, return approval, and not copying tests from the code's table.
Boundary Value Analysis: 2-Value and 3-Value BVA, Off-by-One, and Date, Money and Length Boundaries
Boundary value analysis picks test values at a partition's boundary and its neighbors rather than its middle; the type's and the rule's precision decide what a neighbor is. In Bookstore, with one green test per partition, free shipping at 500.00 TRY, a November campaign shifted to UTC and a last second closed at 23:59:59 were caught only by boundary tests. 2-value and 3-value BVA, date boundaries with FakeTimeProvider, ISBN length and cart size.
Equivalence Partitioning: Splitting Inputs into Classes, Valid and Invalid Partitions, Coverage and Turning Them into xUnit Theories
Equivalence partitioning splits an input into partitions the code should treat the same way and covers each with one test, while every invalid partition gets a test of its own. In Bookstore's order validator, tests combining two invalid values hid a missing guest payment rule; nine tests derived from the partition table caught it and an undefined enum value bug. Each Choice coverage, output partitions and TheoryData.
What Is Test Case Design? Test Conditions, Test Cases, Coverage Goals and Families of Techniques
Test case design means deriving test cases from the requirement rather than by intuition: a chain from test basis to test condition, coverage item, test case and test data. On Bookstore's institutional order rule, five green tests exercising one scenario missed two bugs; eight tests derived from the rule caught both. Black-box, white-box and experience-based techniques and collaboration-based approaches per ISTQB CTFL v4.0.1.
The MSTest 4 Guide: TestClass, DataRow/DynamicData, the Assert API, TestContext, Parallelism, Analyzers and a Quick Look at TUnit
[ExpectedException], removed in MSTest 4, counted an exception of the same type on any line of the method as success; during the upgrade, Assert.ThrowsExactly and a ParamName check exposed a test that had been green for the wrong reason for years and a rule that was never written. MSTest.Sdk and MTP, the decimal pitfall in DataRow, DynamicData, the Assert API, TestContext, parallelism, analyzers, a quick look at TUnit and the close of the series.
The NUnit 5 Guide: Constraint Model, TestCase/TestCaseSource, SetUp/OneTimeSetUp, Parallelism and 5.0 Breaking Changes for xUnit Users
In NUnit 5.0, [Platform("NET")] means modern .NET rather than .NET Framework: an old test that NUnit 4 always skipped on .NET 10 ran for the first time after the upgrade and exposed a real encoding bug in production. An xUnit mapping table, the shared fixture instance, Assert.That constraints, TestCase/TestCaseSource, SetUpFixture, parallelism, MTP and an upgrade from 4.6.1 to 5.0 with real build errors.
The Bogus and AutoFixture Guide: Faker<T> Rules, Turkish Locale, Seeds, Strict Mode, AutoData and Customizations
In Bogus the seed fixes the random number sequence, not the data: a single RuleFor added in the middle of a Faker changes every value after it, so you assert that generated values follow the rules rather than the values themselves. RuleFor, CustomInstantiator, RuleSet, StrictMode, GenerateLazy, a real search bug found with the Turkish locale; a DateOnly customization, the Build pitfall, AutoData and AutoNSubstitute in AutoFixture.
Unit Testing Code That Uses HttpClient: HttpMessageHandler Stubs, MockHttp, IHttpClientFactory and Typed Clients
You fake the HttpMessageHandler underneath HttpClient, not HttpClient itself; a handler that also matches the URL (RichardSzalay.MockHttp) catches bugs such as a missing slash on BaseAddress silently dropping the v2 segment. Your own stub handler, When/Expect and matchers, JSON body matching, testing typed clients and the IHttpClientFactory registration; 429/Retry-After, 5xx, timeout, cancellation and broken JSON scenarios with real failure messages.