boundary-value-generator

Overview

For each bounded input, emit the canonical six-point boundary set (min-1, min, min+1, max-1, max, max+1) per ISTQB boundary value analysis, plus equivalence-class representatives, as parameterized test inputs ready to paste into the project's test runner.

When to use

• A function / endpoint has documented numeric / length / count constraints (age >= 18, name.length <= 100, items.count between 1 and 50).
• A change introduces a new constraint and the team wants systematic boundary coverage in the same PR.
• An existing test suite has happy-path coverage but no boundary cases; the team is filling the gap.
• The acceptance-criteria-extractor produced AC with numeric thresholds; this skill turns each threshold into matching test cases.

Step 1 - Capture the input specification

The skill consumes a structured input spec - for each field:

YAML example:

fields:
  - name: age
    type: int
    min: 18
    max: 120
    nullable: false
  - name: username
    type: string
    min: 3        # length
    max: 30       # length
    regex: '^[a-zA-Z0-9_]+$'
    nullable: false
  - name: tier
    type: enum
    enum_values: [free, starter, pro, enterprise]
    nullable: false
  - name: items
    type: collection
    min: 1        # count
    max: 50       # count
    nullable: true

Step 2 - Apply the generation rules per type

Numeric (int, float)

Six boundary points: min-1, min, min+1, max-1, max, max+1. For float, also include min - epsilon and max + epsilon where epsilon is the platform's smallest representable difference (often 1e-9 is sufficient for business-logic tests).

For age with min=18, max=120:

17, 18, 19, 119, 120, 121

String (length-bounded)

Same six boundary points but applied to length. Generate strings of those lengths from a deterministic source (e.g. repeated 'a', or a Faker call seeded with 42).

For username with min=3, max=30:

""           # length 0 — well below
"a"          # length 1 — well below
"aa"         # length 2 — min-1
"aaa"        # length 3 — min
"aaaa"       # length 4 — min+1
... (string of length 29)    # max-1
... (string of length 30)    # max
... (string of length 31)    # max+1

If a regex is also specified, the cases must satisfy the regex (e.g. [a-zA-Z0-9_]+ rejects empty string and any underscore-prefixed value depending on regex anchors). Generate both regex-matching and regex-violating cases - the latter verifies the rejection path.

Collection (count-bounded)

Same six boundary points applied to count. For items with min=1, max=50:

[]                                   # count 0 — below
[item_1]                              # count 1 — min
[item_1, item_2]                       # count 2 — min+1
[... 49 items]                        # count 49 — max-1
[... 50 items]                        # count 50 — max
[... 51 items]                        # count 51 — above

Item shape comes from the matching factory (Faker / mimesis / FactoryBot - see synthetic-data-toolkit).

Enum

Test each enum value plus one invalid value:

For tier with enum_values: [free, starter, pro, enterprise]:

"free", "starter", "pro", "enterprise", "INVALID_TIER"

The invalid case verifies the rejection path on a typo / removed tier name.

Nullable fields

If nullable: true, also test null / missing. If nullable: false, also test that null IS rejected - the rejection-path case.

Step 3 - Emit in the test-runner-native format

The skill emits cases in the project's test-runner-native format.

pytest

import pytest

@pytest.mark.parametrize("age,expected", [
    (17, "rejected"),
    (18, "accepted"),
    (19, "accepted"),
    (119, "accepted"),
    (120, "accepted"),
    (121, "rejected"),
])
def test_age_boundary(age, expected):
    result = create_user(age=age)
    assert result.status == expected

Jest / Vitest

test.each([
  [17, 'rejected'],
  [18, 'accepted'],
  [19, 'accepted'],
  [119, 'accepted'],
  [120, 'accepted'],
  [121, 'rejected'],
])('age %i is %s', (age, expected) => {
  expect(createUser({ age }).status).toBe(expected);
});

xUnit (.NET)

[Theory]
[InlineData(17, "rejected")]
[InlineData(18, "accepted")]
[InlineData(19, "accepted")]
[InlineData(119, "accepted")]
[InlineData(120, "accepted")]
[InlineData(121, "rejected")]
public void Age_Boundary(int age, string expected)
{
    var result = CreateUser(age: age);
    Assert.Equal(expected, result.Status);
}

JUnit 5 (Java)

@ParameterizedTest
@CsvSource({
    "17, rejected",
    "18, accepted",
    "19, accepted",
    "119, accepted",
    "120, accepted",
    "121, rejected"
})
void age_boundary(int age, String expected) {
    var result = createUser(age);
    assertThat(result.status()).isEqualTo(expected);
}

When NOT to apply boundaries

Some inputs don't have meaningful boundaries:

For those, use equivalence partitioning - group inputs into classes that should produce identical behavior, test one representative per class.

Anti-patterns

Limitations

• Single-input boundaries. This skill covers per-field boundaries; for multi-field interactions (e.g. start_date < end_date), use the broader parameterized-test-generator with pairwise-combinatorial logic.
• Domain-specific boundaries. A "valid US ZIP code" is 5 digits - boundary analysis won't surface that 99999 is valid but 10000 is not (Manhattan vs. Atlantic Ocean). Pair with domain validation rules.
• Float arithmetic. Floating-point boundaries depend on representable precision; epsilon-based testing has its own pitfalls (see Hamming's classical critique).

References

• ISTQB boundary value analysis - canonical definition.
• ISTQB equivalence partitioning - the complementary technique.
• parameterized-test-generator - broader skill including pairwise combinatorial cases.
• negative-test-generator - sibling skill for rejection-path coverage.
• synthetic-data-toolkit - for value generation when the boundary string requires a realistic-looking string.