Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
API Testing with Playwright and Playwright Test Agents: APIRequestContext, Hybrid Scenarios and Using the Planner, Generator and Healer Safely
Giving storageState to an API context does not carry the session in a token-based application: in Bookstore, Ada's own order returned 401. We cover browserless API tests with APIRequestContext, toBeOK, a hybrid scenario that combines the UI and the API, where API tests belong compared with integration tests, and setting up Playwright Test Agents with init-agents, the seed test and reviewing what the planner, generator and healer produce.
Configuring the Playwright Test Runner: playwright.config, Projects, Writing Fixtures (test.extend), test.step, Tags/Annotations and Reporters
In an Angular application, an auto fixture that catches uncaught errors through pageerror sees nothing, because Angular's global error listeners turn the error into a console.error. With real runs on Bookstore we cover playwright.config, timeout layers, projects, a webServer driven by environment variables, writing test- and worker-scoped fixtures, test.step, tags and annotations, merging shards with blob reports, and PageTest on .NET.
The Playwright Assertion Guide: Web-First expect Matchers, Soft Assertions, expect.poll, toPass, Snapshots and Custom Matchers
An assertion that reads the value with textContent() and compares it with toBe does not retry; in Bookstore it reads the total before the coupon applies and fails. With real runs we cover the web-first matcher catalog, the difference between toHaveText and toContainText, expect.soft, expect.poll and toPass, toMatchAriaSnapshot and a custom matcher that keeps the money format in one place; the .NET equivalents are in a table.
The Playwright Locator and Action Guide: From getByRole to filter/and/or, Frames, Shadow DOM, Uploads, Downloads and Dialogs
Silencing a strict mode error with first() does not fix the problem: in Bookstore, a test that picks the out-of-stock edition and times out shows why. With real runs on the institutional order screen we cover getByRole options, narrowing with filter, and and or, actions such as setInputFiles, selectOption and check, and shadow DOM, iframes, dialogs and downloads; the .NET equivalents are in a table.
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.