Before these tests could be flaky if they happened to be called around
the edge of a second. Now we try up to 5 times to execute the tests
while staying within the same second.
This (and still some other methods) just say Expectation error leaving
the user completely in the dark whether the method threw at all.
And since we have nice function printing now we can just toString the
function since most are lambda's.
The ECMA verbiage for modulus is the mathematical definition implemented
by fmod, so let's just use that rather than trying to reimplement all
the edge cases.
Before this would assume that the element found in operator++ was still
valid when dereferencing it in operator*.
Since any code can have been run since that increment this is not always
valid.
To further simplify the logic of the iterator we no longer store the
index in an optional.
This makes it a lot easier to understand what is going wrong when an
eval test fails. As an example instead of just getting:
`ExpectationError`
You would now get:
`ExpectationError: Expected _1_2E+0_1_ to eval to _12_ but got _120_`.
This requires variables that should be exported to the script host
or to other scripts to be declared as var (such as in test-common.js),
since lexically-scoped variables won't be visible.
This regressed recently and would only output a bunch of '[object Foo]',
the reason being that String(value) failed in some cases - which is
easily fixed by trying that first and using Object.prototype.toString()
as a fallback in the case of an exception :^)
Since we have had eval() for a while now, we can finally use it here -
this allows us to get rid of the confusing return statements in tested
source code.
Using String() like we did before depends on objects having either
toString, valueOf, or @@toPrimitive, which is not the case for objects
with no prototype.
The test-js program expects this to exist for 'result: "fail"' results
and would crash if any duplicated test(message) occurs, as we didn't
provide 'details' in that case.
