"DRY is the most obvious one, but one that may be less obvious is for better testing."

Isn't that why we just write functions? Turning simple functions into entire modules just adds an unnecessary level of abstraction that helps nobody.

Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that.

It's like (micro)crowdsourcing (the smallest components of) the standard library that JavaScript never had.

Some bit of logic could go from being DRY in one project, to DRY in all of my projects, ... to eventually be DRY in all projects. It's globally DRY.

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!

>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"?

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

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!

> 100% test coverage is rarely a good thing

Do you mean rarely useful, or actively harmful?

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.

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.

Just to pick at a nit with you, it's a little meaningless to say "100% test coverage", without specifying whether you're talking about line coverage, branch coverage, path coverage...

This is especially true for one-liner modules in js, where any test at all might let you claim 100% statement coverage, without accounting for branches or loops within method calls.

With how weird javascript can be about numbers, it actually didn't surprise me that your module existed.

Actually, thats a good reason to use trivial functions like the one described. Hopefully the author has discovered all of the quirks in Javascript that might affect this. It will likely be a lot more tested than any version I would write.

As someone who spends 80% on the back end, I often get bit on the ass from JavaScripts quirks when I need to add some front end stuff.

That's interesting. JavaScript has enough quirks to warrant an is-positive-integer module.

See:

  isPositive = (x) => +x === x && x > 0

In which conditions does it return a wrong value? I haven't found any.

It would be really, really great if this function was not in its own module, but was part of a larger library in which all such functions of related modules were captured, without the (cognitive and other) overhead of the separate packaging.