How do you constrain Kotest's built-in generators — integers, strings and collections — to a specific range, size or character set, and what goes wrong if you leave the defaults in place?

## Constraints belong in the generator The most common mistake in a first property test is generating a wide domain and then coping with it in the body — filtering, early-returning, or wrapping half the assertion in an `if`. Kotest's built-in generators take their domain as parameters precisely so you do not have to: ```kotlin Arb.int(1..100) // bounded integers Arb.long(0L..1_000_000L) Arb.positiveInt() // shorthand for a common domain Arb.nonNegativeInt() Arb.string(minSize = 1, maxSize = 32, codepoints = Codepoint.alphanumeric()) Arb.list(Arb.int(0..9), 1..10) // element generator + size range ``` This matters for more than tidiness. Three mechanisms follow the constraint. **Edge cases follow the constraint.** An `Arb` mixes declared boundary values into its random stream. When you bound a generator, the boundaries that get injected are *your* boundaries — `1` and `100` for `Arb.int(1..100)`, minimum and maximum size for a bounded list. An unconstrained generator spends its boundary budget on `Int.MIN_VALUE` and the empty string, which may be irrelevant to your contract. **Every iteration stays useful.** Filtering values inside the property (or with a filtering combinator) discards draws: the run does the work of generating and rejecting, and if the acceptance rate is low the effective sample size collapses. A constrained generator produces only usable values. **Runtime is bounded.** Default collection size ranges are generous. If the system under test is expensive — a parser, a serializer, a database round-trip — a thousand iterations over long lists is how a property test becomes the slowest thing in the suite. Bounding size is the cheapest performance fix available. ## Strings: length is only half the problem `Arb.string()` varies both length and character content. The character content is configurable through a codepoint generator — `Codepoint.alphanumeric()`, `Codepoint.ascii()` and similar — and choosing it is a contract decision: - If the field is a username validated to `[A-Za-z0-9]`, generate alphanumeric codepoints. Anything else tests the validator, not the feature. - If the system is supposed to handle arbitrary user text, do **not** narrow the character set — wide unicode is exactly the input class that finds encoding, length-vs-codepoint and normalisation bugs. Many "flaky property" reports are really "the default string generator produced a codepoint the system never promised to accept" or, symmetrically, "the narrow generator hid the multi-byte bug we shipped". ## Numbers: floating point deserves special care Floating-point generators include the classically dangerous values, so a `Double` property can encounter `NaN` and the infinities. `NaN` compares unequal to itself, which breaks naive equality assertions and ordering invariants outright. If those values are out of contract, use a generator restricted to finite numeric doubles or an explicit range — do not litter the property body with guards, and do not "fix" it with a failure tolerance. ## The opposite mistake: over-constraining Narrowing a generator until a property passes is indistinguishable from deleting the test. The discipline is that **every constraint must correspond to a documented contract**: a validated field length, an API-enforced range, a schema limit. If you cannot point at the rule that excludes the input, the input is legal and the code is what needs to change. This is also why constraints are worth reviewing. `Arb.string(minSize = 1)` is a claim that empty input is impossible — if the HTTP layer can deliver an empty body, that claim is wrong and the property has just been told to stop looking at the most likely bug. ## Filter versus constrain Kotest does offer filtering on generators, and it has a legitimate place for conditions that cannot be expressed as a range or size ("a list with no duplicates"). But it has a discard cost: rejected values consume attempts, and a highly selective filter can starve the run. The rule of thumb is: express what you can as a range or size directly on the generator, and reserve filtering for genuinely structural conditions — ideally on a domain already narrowed so the acceptance rate is high. ## A checklist for reviewing a generator 1. Does the numeric range match the validated/documented range? 2. Is the collection size bounded in a way that keeps the property fast? 3. Is the string character set the one the system actually promises to accept — and if the system accepts anything, is the generator wide enough to find encoding bugs? 4. Are floating-point specials in or out of contract, and is that stated in the generator rather than in a guard? 5. Can every constraint be justified by pointing at a rule, or was one added to make a red test green?