Boundary value testing
Testing values at, just below, and just above a limit, where off-by-one and inclusive-range bugs usually hide.
See it
What it is
Boundary value testing checks the points where behavior changes: the minimum, the maximum, and values immediately on either side. If a username allows 3 through 30 characters, the revealing lengths are 2, 3, 4, 29, 30, and 31. Bugs gather there because comparisons, indexing, rounding, and inclusive versus exclusive rules are easy to get wrong. YouTube hit a famous one in 2014, when Gangnam Style approached 2,147,483,647 views and the 32-bit view counter had to be widened.
Reach for it whenever a requirement contains words like at least, less than, maximum, before, after, or expires on. Pair it with equivalence partitioning: choose a representative from each broad region, then spend extra cases around the borders between them.
Gotcha: a boundary comes from behavior, not just from the storage type. Testing JavaScript's Number.MAX_SAFE_INTEGER is noise if the actual rule is 'no more than 100 seats'. Include empty and missing only when they are distinct states, and confirm whether a decimal step, a clock tick, or a calendar day is the meaningful value next to the boundary.
Ask AI for it
Write Vitest boundary value tests for <validationFunction> from its documented minimum, maximum, and step. Use test.each with named rows for min minus one step, min, min plus one step, max minus one step, max, and max plus one step. Add missing, empty, and zero only when the function's contract treats them as distinct inputs. Assert the exact accepted value or validation error, and do not invent boundaries from the TypeScript storage type.