Domain-Constrained Generators in Property-Based Testing

Domain-constrained generators produce test inputs that obey application-specific validity rules instead of drawing arbitrary values from a broad type domain. They make property-based tests more realistic by exploring meaningful states while retaining automated input generation.

A basic property-based generator might produce any `String`, integer, or object permitted by the programming language. Real applications usually impose stronger rules: an order may require at least one line item, an identifier may have a fixed format, and a date range may require the end to follow the start. A domain-constrained generator encodes those rules into input generation.

The generator should construct valid combinations rather than generate independent fields and reject most results afterward. For example, a test case representing a date interval can generate a start date first and then choose an end date relative to it. This avoids wasting test cases on impossible intervals and keeps failures focused on behavior that the application is expected to support.

In Java property-based testing, libraries such as jqwik provide arbitraries that can be transformed, filtered, combined, and recursively composed. A generator can therefore build a domain object from smaller arbitraries while preserving invariants such as non-empty collections, bounded values, or relationships between fields.

Filtering is useful when a constraint is simple, but excessive filtering can make generation inefficient or produce poor coverage. When a constraint describes how values relate to one another, it is generally clearer to construct the dependent value from the value already generated rather than repeatedly generate and discard invalid candidates.

Good generators also preserve diversity. A generator that always creates the same valid shape technically satisfies the domain rules but may miss important boundary conditions and interactions. The goal is a broad sample of valid states, including small, large, empty-where-allowed, boundary, and unusual-but-valid cases.

Key points

• Encode business validity rules directly into generated inputs.
• Prefer construction of related fields over heavy rejection with filters.
• Combine smaller generators to build valid domain objects.
• Preserve variety and boundary coverage within the valid domain.
• Keep generators focused on input validity; test behavioral properties separately.

Interview questions

Why would you use a domain-constrained generator instead of generating arbitrary objects?

Arbitrary objects often contain combinations that the application would never accept. A domain-constrained generator produces inputs that satisfy important validity rules before the system under test sees them. This reduces wasted cases and makes failures easier to interpret. It also lets the test explore many valid combinations automatically.

When should you construct values instead of filtering them?

Construction is preferable when validity depends on relationships between values. For example, after generating a start date, the generator can derive an end date that is guaranteed to be later. Filtering is reasonable for simple constraints where rejection is inexpensive and frequent enough candidates remain available. Excessive filtering can reduce efficiency and make coverage less predictable.

How do domain-constrained generators affect property-based test coverage?

They concentrate generation on states that the application is designed to handle, which can improve the usefulness of each test case. However, restricting the domain too aggressively can remove important boundaries and unusual valid states. A good generator therefore combines validity with diversity. It should deliberately retain meaningful edge cases within the valid domain.

How would you model a domain object whose fields depend on one another?

I would generate the independent parts first and derive dependent fields from them whenever possible. For example, I could generate an order's line items and calculate a total from those items rather than independently generating an unrelated total. That makes the generated object internally consistent by construction. I would then use properties to verify the production code's behavior against those valid objects.