> Test cases are sample based, they do not take care of the whole range of input and output.

Indeed, but they are not random or arbitrary. They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space. If you want to make things water tight, you use formal verification like I mentioned earlier (of which type checking is just a lightweight variant, in a sense) but for general screwups that's not even necessary. If tests are chosen well then the code must be formed very weirdly to produce bugs that the tests would not find.

> They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space.

The thing is you can have code that passes the tests, but are wrong for the general cases. With manual coding, you will have the knowledge that the code is about right, then add test cases to precisely check that intuition.

Like being aware that you used a linear function so as soon as 2 points in the test are ok, the code is right. But if you don’t read the code and have not noticed the quadratic function, your test cases will pass while the code is incorrect.