Normally they really shouldn't, but if you have a problem writing test cases (which probably means you have a problem programming to begin with) then you may not be testing with enough variation in your input to detect corner cases, tests that should come up false etc.
An example:
int fun(int a, int b) {
if (a >= b) {
return 1;
}
return 0;
}
now you could test this by saying:
fun(4,3) should give '1' as the output
and
fun(3,4) should give '0' as the output
But you'd miss to test for equality, with
fun(3,3) which should *also* give 1 as output
So you'd need an extra test for the '=' part of the condition. Replacing '>=' with '>' will still pass the first two tests, so if you forgot about the third you will not even realize something is wrong until your code starts breaking in mysterious ways.
Unit tests have to be just as good as the code you wrote.
An example:
But you'd miss to test for equality, with So you'd need an extra test for the '=' part of the condition. Replacing '>=' with '>' will still pass the first two tests, so if you forgot about the third you will not even realize something is wrong until your code starts breaking in mysterious ways.Unit tests have to be just as good as the code you wrote.