That's not entirely fair - you haven't tested the branches or statements inside the sin function.

However, even if the sin function is already tested elsewhere, you will still need further testing to ensure that you are calling it correctly (e.g. not confusing degrees and radians).

EDIT: Yes, I read it wrong - clearly need coffee...

The original poster gave an implementation of sin(), not a unit test. That implementation has no branches in the source and, for any decent compiler, will not have any branches on the machine, either.

Perhaps you need to read it a little more closely? For the given function, he has indeed tested all the branches and statements.

Also, it's the simplest thing that can possibly work! (And for very small values of x is also the best possible implementation.)

Even better: it's a correctly-rounded implementation for nearly half of the input space!

yep, you're absolutely right. You can get 100% testing coverage when you define it as "percentage of code executed when tests are run".

That said... that kind of coverage isn't quite as useless as it might seem. If your tests do execute every line, even in a completely contrived way, you will catch a lot if you change your code. You just tend to catch more of the "wrong number of arguments passed to a method" kind of error than "you are allowing the autopilot to try to land the plane 100 feet below the runway" kind of error ;)

Careful though with tests that literally execute every line of code: You tie your test to your implementation. That makes even the slightest refactoring difficult. Better to have unit tests that only care about the functional interface.