-
Notifications
You must be signed in to change notification settings - Fork 464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to avoid ambiguity, I agree with @rwaldron
test("0"); | ||
test(Symbol("1")); | ||
test({}); | ||
test([]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this line is not necessary
test(NaN); | ||
test(0n); | ||
test(""); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to avoid ambiguity, I agree with @rwaldron
|
||
testCoercibleToBooleanTrue(function(truthy) { | ||
assert.sameValue(Boolean(truthy), true); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we just throwing this away and assuming this file will only be used with BigInt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
->true
among other tests.