BigInt ToBoolean type coercion test #1241
Conversation
* Number.prototype.toString() has a lot of implementation-specified behavior, which means we shouldn't test something like (123.456).toString(). * Fix copypaste error * ToBigInt error tests should also test ToPrimitive errors.
…here in the same file
| test(NaN); | ||
| test(0n); | ||
| test(""); | ||
| } |
There was a problem hiding this comment.
I'm not sure that I agree with the benefit of the harness function here (which I recognize is similar to others that have been added for these coercion tests). It's not clear in the test file below what is actually being tested, without also seeking out this file and stepping through the layers that have been created. If the test file below contained the following, it would be both sufficient and more easily understood by those that would benefit from test262:
assert.sameValue(Boolean(undefined), false);
assert.sameValue(Boolean(null), false);
assert.sameValue(Boolean(false), false);
assert.sameValue(Boolean(0), false);
assert.sameValue(Boolean(-0), false);
assert.sameValue(Boolean(NaN), false);
assert.sameValue(Boolean(0n), false);
assert.sameValue(Boolean(""), false);
There was a problem hiding this comment.
the code being more verbose helps communicating what it is actually doing, as mentioned. I'd avoid adding too many extras to the harness file so it doesn't become more complex.
There was a problem hiding this comment.
to avoid ambiguity, I agree with @rwaldron
| test("0"); | ||
| test(Symbol("1")); | ||
| test({}); | ||
| test([]); |
There was a problem hiding this comment.
Similar to my comment above, this would be sufficient in a single file:
assert.sameValue(Boolean(true), true);
assert.sameValue(Boolean(1), true);
assert.sameValue(Boolean(-1), true);
assert.sameValue(Boolean(Infinity), true);
assert.sameValue(Boolean(-Infinity), true);
assert.sameValue(Boolean(1n), true);
assert.sameValue(Boolean("a"), true);
assert.sameValue(Boolean("true"), true);
assert.sameValue(Boolean("false"), true);
assert.sameValue(Boolean("0"), true);
assert.sameValue(Boolean(Symbol("1")), true);
assert.sameValue(Boolean({}), true);
assert.sameValue(Boolean([]), true);
| assert.sameValue(Boolean(truthy), true); | ||
| }); | ||
|
|
||
| // `Boolean(value)` (without `new`) never throws. |
| test(NaN); | ||
| test(0n); | ||
| test(""); | ||
| } |
There was a problem hiding this comment.
to avoid ambiguity, I agree with @rwaldron
|
|
||
| testCoercibleToBooleanTrue(function(truthy) { | ||
| assert.sameValue(Boolean(truthy), true); | ||
| }); |
There was a problem hiding this comment.
This should also be placed in 2 different files, at least. We are not trying to condense everything in the same test file. This is also not helpful if anything is failing.
| testPrimitiveValue(BigInt(0)); | ||
| } | ||
| // ToNumber: BigInt -> TypeError | ||
| testPrimitiveValue(0n); |
There was a problem hiding this comment.
are we just throwing this away and assuming this file will only be used with BigInt?
There was a problem hiding this comment.
We need to decide one way or another. In some places in this harness file, BigInt literals are used unconditionally. This check here was pointless, since the file would not parse without BigInt support already. Additionally, the BigInt feature is required for this harness file according harness/features.yml.
This was also a concern when my String.prototype.indexOf type coercion test required BigInt support back in #1200 and #1221. I'm open to discussing more versatility in this regard.
|
Really the main motivation for writing the However, I'm a fan of the type coercion testing framework I've got going in I argue that what I've got in this PR is good organization. A test in the directory
To answer this directly, the test is testing that That's my argument for the elegance of this organization. You're also bringing up practical concerns, like having everything in one file means that if anything fails, then nothing else gets run. We can solve this problem at runtime without creating a combinatoric explosion of individual files. I'll make an independent PR with this idea. |
|
|
This test only uses Boolean right now, but there are a number of contexts that call ToBoolean. For example, |
you're talking about a different thing, which doesn't apply here. The current tests are checking the results for What we have is:
Rather than elegant, these tests are against the design we've been aiming for more than 2 years. I'm not inclined to change the project structure design, neither if this starts with a single test file and not a more comprehensive structural reform. |
Add ToBoolean support to typeCoercion.js harness, and test
0n->false,1n->trueamong other tests.