undefined | Better HN

0 pointstjmehta10y ago0 comments

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a bunch of reasons. DRY is the most obvious one, but one that may be less obvious is for better testing.

I move out modules so I can write really nice tests for the independent of the projects I am using them in. Also, I tend to write projects w/ 100% test coverage, breaking out utils allows me to test projects easier and faster.

Also note, the implementation of this module changed a few times today. With it being open source and having the collaboration of other engineers, we ended up with a very performant version, and discovered interesting quirks about "safe integers" in JS.

0 comments

gizmo38510y ago

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

tedmiston10y ago

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.

1 more reply

TickleSteve10y ago

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!

kristiandupont10y ago

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

mtreis8610y ago

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

1 more reply

serge2k10y ago

> 100% test coverage is rarely a good thing

Do you mean rarely useful, or actively harmful?

TickleSteve10y ago

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.

1 more reply

nvader10y ago

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.

phaedryx10y ago

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

collyw10y ago

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.

augustl10y ago

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

plugnburn10y ago

See:

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

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

Confusion10y ago

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.

j / k navigate · click thread line to collapse

0 comments

gizmo38510y ago

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

tedmiston10y ago

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.

1 more reply

TickleSteve10y ago

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!

kristiandupont10y ago

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

mtreis8610y ago

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

1 more reply

serge2k10y ago

> 100% test coverage is rarely a good thing

Do you mean rarely useful, or actively harmful?

TickleSteve10y ago

Both in a way.

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.

1 more reply

nvader10y ago

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.

phaedryx10y ago

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

collyw10y ago

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.

augustl10y ago

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

plugnburn10y ago

See:

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

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

Confusion10y ago

j / k navigate · click thread line to collapse