Equivalence Partitioning for Non-Numeric Types: Strings, Dates, Enums, and Collections

Most equivalence partitioning (EP) tutorials use age ranges and temperature thresholds. Clean, numeric, easy to understand. The real world is messier: username validation, date ranges with timezone edge cases, enum state machines, and variable-length collections.

This post covers EP for non-numeric input types where the partition boundaries aren't as obvious as "1 to 100."

Review: What EP Is Solving

EP assumes that if a system handles one value in a partition correctly, it handles all values in that partition correctly. This lets you test one representative from each partition instead of every possible value.

The skill is identifying the right partitions. For numeric ranges, partition boundaries are explicit. For other types, you have to derive them from system behavior.

Equivalence Partitioning for Strings

Strings are the most complex input type for EP because they have multiple dimensions: length, character content, encoding, and format.

Length partitions

For a username field (3–20 characters):

These are the same length partitions you'd use for any input — but they only cover one dimension of string validation.

Character type partitions

Most string fields have character restrictions. A username might allow alphanumeric + underscore but reject everything else:

Each character category can behave differently. Null bytes and control characters often bypass string length checks and break downstream processing. Unicode characters may bypass character-allowlist checks.

Format-specific partitions

For email addresses:

For phone numbers, passwords, URLs, credit card numbers — each format has its own partition structure derived from the format specification and common validation failure modes.

SQL injection and XSS partitions

For any string that reaches a database or HTML output:

These partitions aren't about normal valid/invalid — they're security-relevant partitions that verify the system handles potentially malicious input without executing it.

Equivalence Partitioning for Dates and Times

Date EP is complex because of calendar irregularities and time zones.

Date value partitions

For an event date field (must be future date):

The partitions relative to "today" require test setup that pins the current date, or test design that accommodates a moving boundary.

Calendar edge cases as partitions

Many date parsing bugs concentrate at month/year boundaries. February 29 is the classic example: code that fails to account for leap years produces wrong results once every four years.

Timezone partitions

For applications with timezone-aware dates:

Daylight saving time transitions are notorious for revealing timezone bugs. A time that "doesn't exist" (spring forward) or "exists twice" (fall back) triggers edge cases in most time handling libraries.

Equivalence Partitioning for Enumerations

Enums have a different partition structure: there are no continuous ranges, only discrete valid and invalid values.

State machine partitions

For an order status enum with values: PENDING, CONFIRMED, SHIPPED, DELIVERED, CANCELLED:

The partitions aren't just "valid value" and "invalid value" — they're state-dependent. An order in SHIPPED state can transition to DELIVERED or CANCELLED, but not back to PENDING.

EP for state machines: each valid transition is one partition (test one example). Each invalid transition from each state is another partition (test one example of each illegal transition).

For an order, that's at minimum 7 valid transition tests and ~15 invalid transition tests (varies by state machine shape).

Unknown/garbage enum values

Beyond valid enum values, test:

• Null/undefined
• Empty string
• Unrecognized string values ("REFUNDED", "VOID")
• Numeric values if the enum maps to integers
• Out-of-range numeric values

APIs that serialize enums as strings often fail when receiving unrecognized values. The partition "unrecognized enum value" should be explicitly tested.

Equivalence Partitioning for Collections (Lists, Arrays)

Collections have size as a primary partition dimension and element validation as a secondary dimension.

Size partitions

For a cart with 0–50 items:

Empty and single-element collections frequently reveal bugs because:

• Empty: code assumes at least one element (null pointer, division by zero when computing average)
• Single: code assumes multiple elements (min/max comparison logic fails with one element)

Element validity partitions

For a list that should contain only positive integers:

Mixed validity (some valid, some invalid) reveals how the system handles partial validation: does it reject the whole collection, process only valid items, or return an error per invalid item?

Ordering partitions

If the collection order matters (sorted list):

Sorting bugs often manifest at the partitions where no actual sorting is needed (already sorted, single element). These edge cases are underrepresented in tests.

Identifying Non-Obvious Partitions

For complex types, extract partitions systematically:

Step 1: Read the specification What are the explicit rules? Each rule creates at least one partition (satisfies rule) and one (violates rule).

Step 2: Model the behavior What does the system do with this input? Map the input to system behavior. Different behaviors = different partitions.

Step 3: Look for implicit boundaries What values have "interesting" behavior not documented in the spec? String length at database column limits (255, 65535), numeric values at integer overflow points, dates at calendar boundaries.

Step 4: Apply security intuition What values has the OWASP Top 10 shown to cause vulnerabilities? SQL injection strings, XSS payloads, format string attacks for string inputs.

Step 5: Consider the consumer What does the next system do with this input? A string that's valid for your validation but causes a problem in your database, your email sender, or your report generator represents a boundary you need to partition.

Summary

Equivalence partitioning works for any input type that has distinct behavioral regions. For strings: length, character type, format, and security partitions. For dates: value relative to boundaries, calendar edge cases, and timezone. For enums: state machine transitions and invalid values. For collections: size (especially empty and maximum) and element validity.

The discipline: derive partitions from behavior, not from type. Two inputs belong in the same partition if and only if the system behaves identically for both. Different behavior = different partition = needs its own test.