Generating Edge Case Tests with Claude: Finding Boundaries Systematically

1. Why edge cases get overlooked in practice

An edge case is an input value or system state at the boundary of expected behavior, a place where the assumptions of the happy path no longer hold. Developers write tests for the normal case first, because it is the easiest to formulate and maps most directly to the requirement. The edges, where a cart is empty, a discount exactly matches the order total, or a timestamp falls precisely on midnight, are frequently left uncovered, even though a large share of production bugs originate exactly there.

The problem intensifies with system complexity. The more states, permission levels, and external dependencies a feature has, the more combinations of boundary conditions arise, and the less likely it is that a single person can mentally enumerate all of them. Claude can serve as a systematic sparring partner here: instead of relying on one developer's intuition, the code or specification can be queried directly for edge cases, producing a structured list instead of a random sample.

The expectation matters here: generating edge case tests with Claude does not mean the AI fully understands the business logic and automatically judges it correctly. It means Claude derives a broad candidate list from code structure, types, validation logic, and domain terms, which a human then prioritizes and checks against the actual requirement. This division of labor is the core of a productive use of the tool.

2. How Claude identifies edge cases systematically

At its core, Claude searches for edge cases through pattern recognition across known categories: numeric boundaries, empty collections, null values, invalid types, character encoding, time zones, concurrency, and permission boundaries. Given a function signature or a class, the model works through these categories one by one and checks which of them apply to the concrete implementation. The result is noticeably broader than what a single developer thinks through under time pressure.

Input quality is decisive. A prompt that only asks for "edge cases for this function" returns generic answers. If instead the complete function body is provided, including type annotations, validation rules, and neighboring callers, Claude can derive specific boundary conditions, for example that a discount code field is limited to 8 characters and should therefore be tested with both empty strings and overlong input. This precision does not come from magic, it comes from the amount of context available to the model.

A proven approach is the two-step query: first, ask for a category list without concrete test cases, for example "boundary values", "concurrency", "invalid input types". Only in the second step, after a brief manual review of the categories, generate concrete test cases for each relevant category. This two-step approach prevents Claude from spending effort on irrelevant categories and substantially increases the hit rate of the actual test case generation.

# Two-step edge case discovery with Claude Code CLI
# Step 1: category discovery only, no test code yet
claude -p "Read src/Model/PriceCalculator.php and list edge case
categories relevant to calculateFinalPrice(). Only category names
with one-sentence justification, no test code yet."

# Step 2: after manual review, generate concrete test cases
# for the selected categories
claude -p "For PriceCalculator::calculateFinalPrice(), generate
PHPUnit test cases for these categories: boundary values,
empty collections, negative quantities. One test method per case."

3. Prompt strategies for boundary analysis

Boundary value analysis is one of the oldest and most reliable test techniques: errors accumulate statistically at the edges of a valid range, not in its middle. For Claude, this technique translates directly into a prompt pattern by explicitly asking for the values just below, at, and just above a boundary. A prompt such as "For the parameter quantity with a valid range of 1 to 100, name the boundaries and one test case each below, at, and above them" delivers more precise results than an open question about "edge cases for quantity".

A second effective prompt strategy is explicitly naming error state classes: timeout, duplicate request, expired session, concurrent writes to the same record. Claude can propose fitting test scenarios for each of these classes when the class is named concretely, rather than relying on an implicit expectation that the model will prioritize this category on its own. The phrasing "what happens when two requests modify the same cart at the same time" is more concrete and productive than "find all edge cases".

Third, it helps to explicitly ask Claude for the worst realistic case: what is the least likely but still plausible input an attacker or a malfunctioning client could send? This question regularly surfaces test cases that appear in neither the happy path nor classic boundary analysis, for example negative prices from a manipulated API request or a date in the year 9999 from a faulty client.

4. Practical example: edge cases for a price calculation

As a concrete example, consider a price calculation for a cart with quantity discounts and a coupon code, a typical pattern in Magento shops. The core function takes quantity, unit price, discount tier, and an optional coupon code, and computes the final price. At first glance the logic seems simple, yet a short query to Claude already surfaces more than a dozen boundary conditions missing from the original test.

<?php
declare(strict_types=1);

namespace Mironsoft\Pricing\Test\Unit;

use Mironsoft\Pricing\Model\PriceCalculator;
use PHPUnit\Framework\TestCase;

/**
 * Edge case suite generated with Claude for PriceCalculator.
 * Categories: boundary values, empty input, invalid discount codes.
 */
final class PriceCalculatorEdgeCaseTest extends TestCase
{
    private PriceCalculator $calculator;

    protected function setUp(): void
    {
        $this->calculator = new PriceCalculator();
    }

    public function testZeroQuantityReturnsZeroPrice(): void
    {
        $result = $this->calculator->calculateFinalPrice(0, 19.99, null);
        $this->assertSame(0.0, $result);
    }

    public function testNegativeQuantityThrowsException(): void
    {
        $this->expectException(\InvalidArgumentException::class);
        $this->calculator->calculateFinalPrice(-1, 19.99, null);
    }

    public function testQuantityExactlyAtDiscountThresholdApplies(): void
    {
        // Threshold is 10 units — boundary value, not 9 or 11
        $result = $this->calculator->calculateFinalPrice(10, 10.00, null);
        $this->assertEqualsWithDelta(90.00, $result, 0.01);
    }

    public function testQuantityOneBelowThresholdDoesNotApply(): void
    {
        $result = $this->calculator->calculateFinalPrice(9, 10.00, null);
        $this->assertEqualsWithDelta(90.00, $result, 0.01);
    }

    public function testEmptyCouponCodeIsTreatedAsNoCoupon(): void
    {
        $result = $this->calculator->calculateFinalPrice(1, 50.00, '');
        $this->assertEqualsWithDelta(50.00, $result, 0.01);
    }

    public function testCouponCodeWithMaxLengthIsAccepted(): void
    {
        $maxLengthCode = str_repeat('A', 8); // field limit is 8 chars
        $result = $this->calculator->calculateFinalPrice(1, 50.00, $maxLengthCode);
        $this->assertIsFloat($result);
    }
}

The test cases show a recurring pattern: Claude consistently checks the value right at the boundary, not just before or after it, and treats empty strings, null values, and maximum field lengths as their own categories instead of as a special case of the normal path. Without this systematic query, the example would likely have tested only the discount threshold, not the empty coupon string or the maximum code length.

5. Combining boundary value analysis with Claude

Classic boundary value analysis distinguishes between simple boundaries, a single minimum and maximum, and robust boundaries, where values slightly outside the valid range are also considered. Claude can apply either variant on request when explicitly told which one is desired. For security-critical areas such as payment processing, the robust variant is generally advisable, because even a slightly invalid input, for example a price of minus one cent, can lead to unacceptable results there.

A practical trick is asking Claude to output the boundary values in a table with the corresponding test expectation, before the actual test code is written. This intermediate table can be reviewed and corrected by a developer within minutes, much faster than reviewing finished test code. Only once the table is factually correct is it translated into PHPUnit, Jest, or Pytest code. This intermediate artifact reduces the chance that a factually wrong test case slips unnoticed into the suite.

6. Covering null, empty, and error states

One of the most productive categories for edge case tests is null and empty states: an empty order, a customer account without an address, a product variant without a price. These states are usually permitted from a business perspective, but are often implicitly excluded in the implementation, because the developer unconsciously assumes a populated state while writing the happy path. Claude can be asked specifically to name the empty or null case for every collection and optional field in the code and to derive a test case from it.

Error states go a step further: what happens when an external dependency, for example a payment API, returns an error, triggers a timeout, or delivers an unexpected response structure? Claude can propose mocks and stubs for such scenarios that simulate exactly these error paths, instead of focusing only on the successful return value. In practice, error paths in integration tests are often completely missing, because they were not the focus when the feature was first written.

<?php
declare(strict_types=1);

namespace Mironsoft\Payment\Test\Unit;

use Mironsoft\Payment\Model\PaymentGateway;
use Mironsoft\Payment\Model\PaymentGatewayClientInterface;
use PHPUnit\Framework\TestCase;

/**
 * Edge case suite for error paths of an external payment dependency.
 * Generated with Claude after specifying the failure classes explicitly.
 */
final class PaymentGatewayErrorPathTest extends TestCase
{
    public function testGatewayTimeoutIsTranslatedToRetryableException(): void
    {
        $client = $this->createMock(PaymentGatewayClientInterface::class);
        $client->method('charge')->willThrowException(new \RuntimeException('timeout'));

        $gateway = new PaymentGateway($client);

        $this->expectException(\Mironsoft\Payment\Model\Exception\RetryablePaymentException::class);
        $gateway->charge(19.99, 'tok_test');
    }

    public function testUnexpectedResponseShapeDoesNotCrashSilently(): void
    {
        $client = $this->createMock(PaymentGatewayClientInterface::class);
        // Response missing the expected "status" field entirely
        $client->method('charge')->willReturn(['unexpected_field' => true]);

        $gateway = new PaymentGateway($client);

        $this->expectException(\Mironsoft\Payment\Model\Exception\MalformedResponseException::class);
        $gateway->charge(19.99, 'tok_test');
    }
}

7. Edge cases for APIs and interfaces

For REST and GraphQL interfaces, the focus shifts from internal function boundaries to external contract violations: missing required fields, wrong content type, overlong payloads, unexpected character encodings. Claude works well to systematically derive, from an OpenAPI specification or a GraphQL schema, the set of invalid requests a client could theoretically send, even if the application itself normally never generates such requests.

This approach is especially valuable for API versioning and backward compatibility: given two schema versions, Claude can formulate concrete test cases that check whether an older client still gets served correctly when new fields are missing. Such compatibility gaps are rarely tested manually in practice, because they are cognitively demanding to reason through, and that is exactly why they benefit strongly from structured AI-assisted analysis.

{
  "edge_case_requests": [
    {
      "name": "missing_required_field",
      "payload": { "sku": "TEST-001" },
      "expected_status": 422,
      "reason": "quantity field is required but omitted"
    },
    {
      "name": "quantity_at_upper_boundary",
      "payload": { "sku": "TEST-001", "quantity": 999 },
      "expected_status": 201,
      "reason": "999 is the documented maximum order quantity"
    },
    {
      "name": "quantity_above_boundary",
      "payload": { "sku": "TEST-001", "quantity": 1000 },
      "expected_status": 422,
      "reason": "one unit above the documented maximum"
    },
    {
      "name": "duplicate_idempotency_key",
      "payload": { "sku": "TEST-001", "quantity": 1, "idempotency_key": "abc-123" },
      "expected_status": 409,
      "reason": "same idempotency key sent twice in a row"
    }
  ]
}

8. Integrating into existing test suites

Edge case tests generated with Claude should not exist as an isolated special file next to the existing suite, they should be integrated as regular test classes into the same directory structure and CI pipeline. A proven pattern is a distinct naming suffix such as EdgeCaseTest, which stays clearly identifiable in reports but is technically treated the same as any other PHPUnit or Jest test. That way, the generated tests do not disappear into a separate script that eventually gets forgotten.

For traceability, it is worth documenting in a comment on every generated test case which edge case category is covered and that the test case originated with Claude's assistance. This documentation helps future code reviewers understand the intent behind a seemingly exotic test case, instead of accidentally deleting it as superfluous. Especially for rare edge cases, this context is decisive for the suite's long-term maintainability.

# Run only the generated edge case suite in CI, separate report target
vendor/bin/phpunit --testsuite EdgeCases \
  --log-junit var/log/edge-case-results.xml

# Combine with the regular suite for the full coverage report
vendor/bin/phpunit --testsuite Unit,EdgeCases \
  --coverage-html var/log/coverage-html

9. Limits: what Claude does not find reliably

Claude knows the written specification and the code, but not the unwritten domain knowledge that only exists in the heads of experienced colleagues, for example a historically grown special rule for one single large customer. No AI reliably finds such implicit edge cases, because they are not documented anywhere accessible to the model. Claude also struggles with prioritizing by business risk: the model lists categories with roughly equal weight, while an experienced tester knows which edge case actually caused a production incident last quarter.

The table shows the decisive point: neither the purely manual nor the purely AI-assisted variant delivers the best result. Only the combination of Claude's systematic breadth and business prioritization by the team leads to a test suite that both covers many edge cases and addresses the actually risky ones first.

10. Summary

Generating edge case tests with Claude means systematically querying code, specification, and domain terms against known categories such as boundary values, empty states, error paths, and concurrency, instead of relying on random intuition. The two-step query, categories first, then concrete test cases, delivers more precise results than an open question about edge cases. Concrete examples such as the price calculation show that Claude reliably proposes boundary values, empty inputs, and maximum field lengths as their own test cases.

The greatest value comes from combining Claude's systematic breadth with business prioritization by the team: Claude finds the candidates, humans decide which ones matter commercially. Anyone who cleanly integrates generated edge case tests into existing PHPUnit suites and CI pipelines, and documents the origin of each test case, ends up with a test suite that covers substantially more edge cases than one written purely by hand.

11. FAQ: Generating Edge Case Tests with Claude