“It is never a compiler error”

Re:“It is never a compiler error” by flukus on Tuesday November 14, 2017 @05:55PM (#15700022)

For me it's that they aren't testing it. This sort of functionality is so trivial to write unit tests for, so simple that it's the fastest and easiest way to write and debug the sort method.

It'd make me question the stability of the rest of their product too.

[ Parent | on HN ]

Re:“It is never a compiler error” by islemaster on Tuesday November 14, 2017 @07:59PM (#15700704)

Actually, that's a fascinating part of the story. We run the entire test262 ECMAScript Conformance Suite (https://github.com/tc39/test262) against our JS-Interpreter fork. We don't pass the whole thing yet, but it ensures we only ratchet toward conformance to the language spec.

We checked, and this particular bug was not caught by the test262 suite - the broken sort worked for enough cases to slip past the Array.prototype.sort tests there. We've added a regression test for this issue in the layer that consumes the interpreter, but I've thought about proposing more aggressive validation of sort behavior to the test262 project.

It was a great reminder to me that while tests may be necessary for quality, they are not always sufficient!

Brad, Code.org Engineering

[ Parent | on HN ]