2) You can't prove correctness with tests. You can only state that it ran correctly for that test case(s).
2) You can't prove correctness with tests. You can only state that it ran correctly for that test case(s).
Good test vectors are a great investment, as are constraint checks and supporting instrumentation of said constraint checks.
For example proof assistants(like Coq, Agda, Idris, hol) are capable of proving correctness of a program.
But you are right, tests are biased. Pair programming can reduce the chance of code/tests being biased in a negative way.
For example: int addOne(int input) function would need test cases for every number in the int type, which would be 2,147,483,647 * 2 + 1 test case.
IE, a test is another way to explain what the developer of that test cared about, worried about, needed to verify of the code that is exercised.
Also, tests provide anothing built in consumer of the code, and all code with more consumers is better code, purely by surviving the stress.
I think random testing is a good way to get almost exhaustively tests.
> I think random testing is a good way to get almost exhaustively tests.
I think that testing known/predictable edge and corner cases makes more sense (in some cases), but I also think that I was responding to a comment about the impossibility of using tests to prove correctness of a function, not about how to derive practical benefits despite theoretical limitations.
You are right, you can use tests to prove a function if - the function has very limited arguments and - the function is pure or does very limited amount of state change(side effect)
Generally speaking tests are not the right tool for proving program correctness.