[TickleSteve]

Two points:

- Breaking out is-positive-integer hasn't reduced the number of paths to test. You have not gained anything, you've added overhead.

- 100% test coverage is rarely a good thing. It is required for safety critical areas like avionics. I can guarantee that your JS code is not making into any safety critical environment!

[kristiandupont]

>hasn't reduced the number of paths to test

But it has: it's now tested, and you don't need to write tests for it next time you want to use it.

>100% test coverage is rarely a good thing

Not sure what your argument is here. Sure, it may not be helpful but are you saying that one should strive for less than 100% coverage, because "it's rarely good"?

[mtreis86]

100% coverage is rarely worth the time, unless it's an engine controller or something else that needs the assurances.

[Confusion]

If tjmehta likes to cover his open source code 100%, under whatever metric, by God let's encourage him in that and not start a discussion about the economic sense of it!

[serge2k]

> 100% test coverage is rarely a good thing

Do you mean rarely useful, or actively harmful?

[TickleSteve]

Both in a way.

What happens when you have a "100% test coverage" requirement is that people don't think about the tests, they simply make tests to force the code down every path without thinking whether it was intended to operate like that.

For example if the is-positive-integer had a silly test for "if(value==23) return false", a requirement for "100% test coverage" would simply result in someone creating a test for that condition instead of considering if it was actually a fault.

100% test coverage != no faults.

What you have done by generating 100% test coverage is effectively 'frozen' your code and made it harder to implement any changes.

[ademarre]

I would say that what's most harmful is using code coverage as the primary measure of quality of your tests. It's that mindset that puts coders in a mode where they write tests which upon failure mean nothing significant (unless it finds a runtime error). It's a type of fallacy. Instead of considering if your tests verify your real-world requirements, you feel like your job is done because you have reached 100% line coverage.

It's like following someone's car and congratulating the driver that he drove correctly, without considering if he reached the correct destination.