A Kotest property keeps failing on an injected boundary value — an empty string, or an extreme integer — that your domain can never actually contain. How do you deal with that, and what is the risk of the obvious fix?

## Why the boundary value showed up kotest-property generators do not sample uniformly at random. Alongside random values they inject *edge cases* — the values that historically break code: empty strings and empty lists, zero, negative numbers, minimum and maximum values of a numeric type, nulls for nullable generators. This is a deliberate policy: purely random sampling from a 64-bit space almost never produces zero, and zero is where the bugs are. So when your property fails on `""` or `Int.MIN_VALUE`, the framework is doing its job. The question is whether *your* code is supposed to handle that value. ## The decision **Case A — the value cannot occur.** The field is validated at the boundary of the system, or the type genuinely constrains it: an `age` column is `CHECK (age BETWEEN 0 AND 120)`, a request DTO is rejected before this function is reached. Then the generator is over-broad: it is testing a contract you never promised. The fix belongs in the generator. **Case B — the value can occur, you just did not think about it.** Empty strings arrive from web forms all the time; a quantity of zero is a legal cart state; `Int.MIN_VALUE` reaches an `abs()` call in real code. Then the property has found a genuine defect and the only correct response is to fix the code or, where the precondition is real and enforced elsewhere, make the precondition explicit rather than silently deleting the sample. Most teams get this wrong in the same direction: they suppress the edge case because the build is red, and lose the finding. Answer Case A vs Case B out loud before touching the generator. ## Expressing the real domain The best fix is almost always to constrain at the source, because a constrained generator documents the legal input space for the next reader: ```kotlin val ageArb = Arb.int(0..120) // not Arb.int().filter { it in 0..120 } val nameArb = Arb.string(minSize = 1, maxSize = 64) ``` A bounded generator still injects boundary values — but *its* boundaries (0 and 120), which are exactly the ones you want tested. When the generator's shape is right and only the boundary set is wrong, kotest-property lets you replace it: ```kotlin val currencyArb = Arb.of("EUR", "USD", "GBP").withEdgecases("EUR") val quantityArb = Arb.int(1..100).withEdgecases(1, 100) ``` `withEdgecases` returns a generator with your list of edge cases in place of the built-in ones — useful for domain types where "interesting boundary" means something specific (the smallest legal order, the last day of a billing period) that Kotest cannot guess. You can also pass an empty list to stop boundary injection for that generator entirely; do that consciously, knowing what you are giving up. ## The risk, stated plainly Edge cases are the highest-yield samples in the run. Removing them makes a suite *look* the same — same iteration count, same green tick — while quietly losing most of its bug-finding power. Two guard rails: 1. **Never suppress an edge case to make a red build green** without first deciding it is impossible in production. Write the reason in a comment next to the generator. 2. **Prefer constraining over suppressing.** `Arb.int(1..100)` says "the domain is 1..100" and still tests its own boundaries; `Arb.int().withEdgecases()` says nothing and tests fewer interesting values. ## Interaction with shrinking and replay Edge cases participate in the same machinery as everything else: a failure on an injected boundary shrinks like any other failure, and the run's seed reproduces it. Changing a generator's edge cases changes what a given seed produces, so an old seed will not replay after you edit the generator — capture the shrunk counterexample as an example-based test before you start editing. ## What interviewers are listening for The judgement, not the API. A strong answer separates "impossible" from "inconvenient", names constraining as the preferred fix and `withEdgecases` as the precise one, and explicitly flags the failure mode of suppressing boundaries to keep a build green.