Skip to content
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

add BigInt tests #1148

Closed
wants to merge 1 commit into from
Closed

add BigInt tests #1148

wants to merge 1 commit into from

Conversation

cxielarko
Copy link
Contributor

These are tests for the BigInt proposal

@cxielarko
Copy link
Contributor Author

This patch primarily tests integration with the rest of the language (syntax, type conversions, library methods, etc.) and doesn't include detailed arithmetic tests. Tests for the typed arrays and DataViews are also missing. I'm planning to submit more arithmetic tests in a separate patch.

@leobalter
Copy link
Member

leobalter commented Jul 11, 2017 via email

Copy link
Member

@littledan littledan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are a good start. I don't see any bugs, just room for more tests.

Generally, there's a lot more Number tests than BigInt tests in this patch. You could write a lot of tests by copying over the relevant ones and updating them for BigInt semantics.

You can also include an info: section in the tests which copies the relevant block of spec text.

features: [BigInt]
---*/

assert.sameValue(BigInt.asIntN(1, 3n), -1n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add some more tests for:

  • Passing a non-Index argument for the first argument (e.g., -1, or "foo")
  • Passing a non-BigInt argument for the second argument
  • If both are objects with valueOf methods, then the index is first (sorry, just changed this Normative: Reverse the order of casts for asIntN/asUintN proposal-bigint#52)
  • Testing a wider range of values to get a little more confidence in the arithmetic
  • Superficial things like, what's the length of the function, check that it's a writable, non-enumerable and configurable property.

// This code is governed by the BSD license found in the LICENSE file.

/*---
description: BigInt constructor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could write something here like, "if the argument to the BigInt constructor is not a safe integer, throw a RangeError."

assert.throws(RangeError, () => BigInt(-x));
}
assert.sameValue(BigInt(9007199254740991), 9007199254740991n);
assert.sameValue(BigInt(-9007199254740991), -9007199254740991n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more tests you can write for the constructor:

  • Taking a string as an argument (should parse similarly to the parseInt tests below, except there is no radix argument)
  • An object (should call ToPrimitive appropriately)
  • The length and property attributes of how it's installed on the global object, as described above.

assert.throws(SyntaxError, () => BigInt.parseInt("1", 37));
assert.sameValue(BigInt.parseInt("0xf", 0), 0xfn);
assert.sameValue(BigInt.parseInt("-0"), 0n);
assert.sameValue(BigInt.parseInt(" 0@"), 0n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this suffix allowed?

assert.sameValue(BigInt.parseInt("-0"), 0n);
assert.sameValue(BigInt.parseInt(" 0@"), 0n);
assert.sameValue(BigInt.parseInt("kf12oikf12oikf12oi", 36),
5849853453554480289462428370n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding a test that one more than this parses as a distinct BigInt?

features: [BigInt]
---*/

const ToString = (x) => x + "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test that BigInt + String works the other way around as well, and with non-empty strings, and that it also works with these things in object wrappers.

features: [BigInt]
---*/

assert.throws(RangeError, () => 1n / 0n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0n/0n as well?

assert(1n != false);
assert(0n != NaN);
assert(0n != Infinity);
assert(0n != -Infinity);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Rather than just assert(), use assert.sameValue(true, ...) to be completely sure that this outputs a boolean.
  • Share the tests from the "equals" assertions, except asserting that the output is false
  • Include a test which requires some calculation to compare the BigInt to the Number

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's a lot of observation parts here that I can't get an exact reference for all of these cases combined.

https://tc39.github.io/proposal-bigint/#sec-abstract-equality-comparison

assert(1n >= 0);
assert(1 >= 0n);
assert(1n >= 1);
assert(1 >= 1n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include some test which requires a little bit more calculation, and include a comparison between some non-numeric types and a BigInt.

---*/

assert.sameValue(!!0n, false, "Expected ToBoolean(0n) to be false");
assert.sameValue(!!1n, true, "Expected ToBoolean(1n) to be true");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also test this through if, ||, &&, ?:.

@cxielarko
Copy link
Contributor Author

cxielarko commented Jul 13, 2017

I used a checklist like the following, based on the proposal's TOC, to develop the initial tests. (It could probably be more detailed, e.g. listing which interactions between features are tested)

(List moved to issue #1056)

@leobalter leobalter added the awaiting stage 2.7 Supports a "Stage 2" feature label Jul 13, 2017
@leobalter leobalter removed the awaiting stage 2.7 Supports a "Stage 2" feature label Aug 24, 2017
@leobalter
Copy link
Member

I'm working on a follow up for this today.

@littledan
Copy link
Member

Landed as #1198

@littledan littledan closed this Aug 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants