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.

Because the author wrote poor tests and thinks that you did too.

It shows that green bars on all your tests don't necessarily mean anything. All too often, developers don't test for the cases that may actually fail (because, obviously, their actual code is only correct for the cases they're cognizant of).

Because they are arbitrary and not a one-to-one correspondence with what they purport to be testing. One false positive and everything could still be broken.

Never tried it. But its probably because unit tests can only tests things you explicitly test for and if you don't have your corner cases covered, then these changes wouldn't blow up your tests. Someone correct me if I'm wrong.

Not a fan of unit testing my self. I feel the approach lacking.

That's the horror.