How to decide on the amount of test cases for smaller than functionality?

I have some function that does one thing for 5 cases that conveniently have the values 1 to 5 and something else for the other cases. The possible values come from an API that currently has ~100 values but is constantly growing.

I want to unit-test that function that contains code like this:

if( currentCase < 6){
    do one thing
}else{
    do the other
}

Very simple. But how about the unit-test test-cases? I can test that all 5 cases do the one thing e.g.:

TestCase(1)
TestCase(2)
TestCase(3)
TestCase(4)
TestCase(5)

But what about the other thing? Do I just test 6? Or how about 5 evenly distributed cases: 6 26 46 66 86?

While looking for answers to this question I came across advice that said to take the implementation into account (x<6) but isn't the general idea of unit test, that they should break when someone changes the implementation and that doesn't anymore comply with previous desired behavior? E.G. someone changes my code to this:

if( currentCase < 6  || currentCase == 50){
    do one thing
}else{
    do the other
}

That won't break the unit-test if I don't test extensively. Should I try to predict how people are gonna change my code while picking the test-cases?

Basically I want a reliable test that documents the desired behavior but is still readable. This question has many interesting answers but I still couldn't find any satisfactory guides/rules/best practices for this case.