Skip to content

Add new test #2578

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

Merged
merged 1 commit into from
Nov 22, 2018
Merged

Conversation

repasics
Copy link
Contributor

Added unusual-javascript-constructs.js to test corner cases

JerryScript-DCO-1.0-Signed-off-by: Csaba Repasi [email protected]

Copy link
Contributor

@loki04 loki04 left a comment

Choose a reason for hiding this comment

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

It looks fine by me.

assert ([] + [] == "");
assert ([] + {} == "[object Object]");
//assert({} + [] == 0); // FIXME: assertion failed, it should be 0, but it is [object Object]
//assert({} + {} == NaN); // // FIXME: assertion failed, it should be NaN, but it is [object Object][object Object]
Copy link
Contributor

Choose a reason for hiding this comment

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

Please create new issues for these two ones! It probably worth to add the link of the issues here as well.

Copy link
Member

Choose a reason for hiding this comment

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

There is no need to add new issues and also the assertions are wrong.

The correct asserts would look like:

assert (eval ("{} + []") == 0)
assert (isNaN (eval ("{} + {}"))); // isNaN should be used instead of == NaN

The reason behind this is how {} is being parsed.

  • As a block (That's why {} + [] evaluates to 0, since {} evaluates to an empty block, and +[] gives 0 as a result)
  • As an object literal (putting this check in an assert the {} becomes a part of an expression so it's interpreted as an object)

Also these test cases should be added with a bit modification:

assert ({} + [] == "[object Object]")
assert ({} + {} == "[object Object][object Object]");

Copy link
Member

Choose a reason for hiding this comment

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

This is strange. I've just built jerry and the interactive shell gives me:

jerry> {} + {}
NaN

That's not [object Object][object Object].

Moreover, the assert couldn't be passing anyway as comparing anything to NaN (NaN included) gives false.

Copy link
Member

Choose a reason for hiding this comment

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

(To clarify: my above comment "This is strange" is not a response to @rerobika but a reaction to the commit itself. We must have been typing our reviews in parallel.)

Copy link
Member

@rerobika rerobika Oct 29, 2018

Choose a reason for hiding this comment

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

@akosthekiss That's the expected behavior. Since you are using the shell, it evaluates the given line, so the output is correct. (same for the other test case)

jerry> {} + [] // parse {} as an empty block
0
jerry> print ( {} + [] ) // parse {} as an object literal ( now {} is a part of an expression)
[object Object]
undefined

Copy link
Member

@akosthekiss akosthekiss left a comment

Choose a reason for hiding this comment

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

I've found lots of cases already being tested elsewhere. I'm not sure it's worth duplicating them.

assert (x == !x);
assert (Array(3) == ",,");

assert (typeof NaN == "number");
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested by test262/test/suite/ch08/8.5/S8.5_A3.js and test262/test/suite/ch15/15.1/15.1.1/15.1.1.1/S15.1.1.1_A1.js

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with you. If the test case exists elsewhere in the repository, there is no reason to duplicate it.

assert (Array(3) == ",,");

assert (typeof NaN == "number");
assert (NaN != NaN);
Copy link
Member

Choose a reason for hiding this comment

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

(almost) this is being tested in test262/test/suite/ch11/11.9/11.9.2/S11.9.2_A4.1_T1.js and _T2.js (and the !== version at several other places)


assert (typeof NaN == "number");
assert (NaN != NaN);
assert (typeof null == "object");
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested in jerry/typeof.js

assert (NaN != NaN);
assert (typeof null == "object");
assert (!(null instanceof Object));
assert (!("string" instanceof String));
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested in jerry-test-suite/11/11.08/11.08.06/11.08.06-004.js

assert (9999999999999999 == 10000000000000000);
assert (0.1 + 0.2 != 0.3);
assert (!(Math.max() > Math.min()));
assert (Math.max() < Math.min());
Copy link
Member

Choose a reason for hiding this comment

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

the expected values of Math.max() and Math.min() are being tested in jerry-test-suite/15/15.08/15.08.02/15.08.02.11/15.08.02.11-009.js and -010.js. -Infinity  < Infinity is being tested in test262/test/suite/ch11/11.8/11.8.1/S11.8.1_A4.6.js

//assert({} + [] == 0); // FIXME: assertion failed, it should be 0, but it is [object Object]
//assert({} + {} == NaN); // // FIXME: assertion failed, it should be NaN, but it is [object Object][object Object]

assert (true + true === 2);
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested in test262/.../S11.6.1_A3.1_T1.1.js

//assert({} + {} == NaN); // // FIXME: assertion failed, it should be NaN, but it is [object Object][object Object]

assert (true + true === 2);
assert (true - true === 0);
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested in jerry-test-suite/.../11.06.02-010.js


assert (true + true === 2);
assert (true - true === 0);
assert (!(true === 1));
Copy link
Member

Choose a reason for hiding this comment

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

this is being tested in test262/.../S11.9.4_A8_T1.js

assert ([] + [] == "");
assert ([] + {} == "[object Object]");
//assert({} + [] == 0); // FIXME: assertion failed, it should be 0, but it is [object Object]
//assert({} + {} == NaN); // // FIXME: assertion failed, it should be NaN, but it is [object Object][object Object]
Copy link
Member

Choose a reason for hiding this comment

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

This is strange. I've just built jerry and the interactive shell gives me:

jerry> {} + {}
NaN

That's not [object Object][object Object].

Moreover, the assert couldn't be passing anyway as comparing anything to NaN (NaN included) gives false.


assert ([] + [] == "");
assert ([] + {} == "[object Object]");
//assert({} + [] == 0); // FIXME: assertion failed, it should be 0, but it is [object Object]
Copy link
Member

Choose a reason for hiding this comment

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

This also seems to work for me in the interactive shell:

jerry> {} + []
0

Copy link
Member

@akosthekiss akosthekiss left a comment

Choose a reason for hiding this comment

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

My previous comments about most probably superfluous duplications of test cases have neither been answered nor actioned. But I see a new commit uploaded. This is a direct request now to remove the duplications.

assert ({} + [] == "[object Object]");
assert (isNaN (eval ("{} + {}")));

assert ((! + [] + [] + ![]).length === 9);
Copy link
Member

Choose a reason for hiding this comment

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

This should rather be compared to "truefalse" instead of its length only.


assert (!(null instanceof Object));

assert (9999999999999999 == 10000000000000000);
Copy link
Member

Choose a reason for hiding this comment

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

this might be a better fit in tests/jerry/arithmetics-bignums.js (it already contains similar edge cases)

assert (!(null instanceof Object));

assert (9999999999999999 == 10000000000000000);
assert (0.1 + 0.2 != 0.3);
Copy link
Member

Choose a reason for hiding this comment

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

this might go to tests/jerry/arithmetics-2.js which already contains a floating point imprecision test

assert (eval ("{} + []") == 0);
assert (isNaN (eval ("{} + {}")));
assert ({} + [] == "[object Object]");
assert (isNaN (eval ("{} + {}")));
Copy link
Member

Choose a reason for hiding this comment

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

something ain't right here.: {} + [] is tested with and without eval but {} + {} is tested with eval only (but twice).

assert (x == !x);
assert (Array(3) == ",,");

assert (!(null instanceof Object));
Copy link
Member

Choose a reason for hiding this comment

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

Something like this is tested in tests/test262/test/suite/ch15/15.3/15.3.5/S15.3.5.3_A1_T6.js (testing [[HasInstance]]) but I agree that it's not completely the same. But then, this might deserve its own test case in tests/jerry-test-suite/11/11.08/11.08.06/ (tests of instanceof), a new 11.08.06-008.js test file.

@@ -0,0 +1,32 @@
// Copyright JS Foundation and other contributors, http://js.foundation
Copy link
Member

Choose a reason for hiding this comment

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

"javascript" in the file name doesn't carry too much information (considering that this is the test suite of a javascript engine). I think tests/jerry/unusual.js would be enough.

@akosthekiss akosthekiss added the test Related to testing label Oct 31, 2018
@@ -28,6 +28,8 @@ assert(c == 210);
c = a / b;
assert(c >= 2.1 - 0.000001 && c <= 2.1 + 0.000001);

assert (0.1 + 0.2 != 0.3);
Copy link
Member

Choose a reason for hiding this comment

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

Interesting choice to insert this in the middle of the a-b-c-related checks. Why not at the end of the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've inserted it there because there is the only floating point check in the file. I tought it fits there.

Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest moving it to the end.

Added tests/jerry/unusual.js to test corner cases
Added tests/jerry-test-suite/11/11.08/11.08.06/11.08.06-008.js (a new test of instanceof)
Added new floatingpoint test case to tests/jerry/arithmetics-2.js
Added new test case to tests/jerry/arithmetics-bignums.js

JerryScript-DCO-1.0-Signed-off-by: Csaba Repasi [email protected]
Copy link
Member

@akosthekiss akosthekiss left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@LaszloLango LaszloLango left a comment

Choose a reason for hiding this comment

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

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Related to testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants