= Solution
<Black-box testing> chooses inputs and expected outputs from the public specification without using the implementation's control structure. <Equivalence class testing> partitions the input space into classes expected to exercise similar specified behavior, then chooses representatives; boundary cases test where that behavior changes. For <equal-range search>, use these concrete representatives:
* Empty <array>: `([], 4)` gives \b[`(0,0)`].
* One entry, with the target below, equal, and above it: `([4],3)`, `([4],4)`, `([4],5)` give \b[`(0,0)`, `(0,1)`, `(1,1)`].
* An absent interior value: `([1,3,5],4)` gives \b[`(2,2)`].
* One interior match: `([1,3,5],3)` gives \b[`(1,2)`].
* A repeated interior block: `([1,3,3,3,5],3)` gives \b[`(1,4)`].
* A repeated block touching the left or right boundary: `([3,3,5],3)` and `([1,3,3],3)` give \b[`(0,2)`] and \b[`(1,3)`].
* Every entry equal: `([3,3,3],3)` gives \b[`(0,3)`]; targets two and four give \b[`(0,0)`] and \b[`(3,3)`].
* Extreme keys: `([Int.MinValue,0,Int.MaxValue],Int.MaxValue)` gives \b[`(2,3)`], and searching for `Int.MinValue` gives \b[`(0,1)`].
For each result independently check $0\leq i\leq j\leq n$, the strict inequalities outside the returned interval, and equality inside it. Unsorted inputs violate the <precondition>; they are not ordinary members of the specified valid-input classes. <Software testing> supplies evidence about implementations, while the <loop invariant> proof explains correctness for every valid input.
Back to article page
