The way the stored procs are coded, they pretty much assume (from their limited generality) that contiguous integers partition differently - they should definitely say so in their class or run method comments.
In reality, the way that the methods are applied, here the assumption only has to apply to 0 and 1 vs. the general case (would also be good to note in a comment).

Better yet -- in the face of who-knows-what the elastics are doing to hashing -- it would be better if the test self-validated different partitionings for the values it uses or better yet adapted itself. One possible scheme:

    call an SP insert with a 0 partition key.
    do forever {
        call an SP insert using an incremented partition key.
        for key from 0 to last_inserted-1 {
            call an SP "select found_key from table;" with key as the unused partition key.
            if the result is non-empty and does not contain last_inserted // this rules out two coincidentally same partitionings
                break from both loops
        }
    }
    call (custom) SP insert and update methods passing one of (last_inserted, found_key) as the partition key and the other as the new value.