-
Notifications
You must be signed in to change notification settings - Fork 13
Add test for Number.prototype.chr
goody
#395
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 test for Number.prototype.chr
goody
#395
Conversation
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 too sure if I'm able to view this, since it's considered a Binary file?
I can see the file at https://github.com/code-chronicles-code/leetcode-curriculum/blob/2ad7586de4ae68d10661131c29882dea5d5cf920/workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts but yeah, for some reason GitHub thinks it's a binary file. @Gobleizer I'm not sure which of the non-ASCII characters is the culprit... Emojis are usually fine. |
I believe it is the Null Character (https://unicode-explorer.com/c/0000) which is the result when you attempt to get a character from number 0. |
Perhaps we should use escapes for the null character? So |
Awesome point. Fixed. |
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.
hey @Gobleizer Thanks for the PR and fixing the file stuff!
I have a couple of nits.
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
Number.prototype.chr
goody
What do you all think if I added inner describe blocks? |
Yeah I went ahead and nested the describe blocks. |
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.
Hey @Gobleizer. Nice job on working on this PR! I have just one comment, but I think overall is good.
describe("convert ASCII codepoint to ASCII string", () => { | ||
it.each([ | ||
{ codepoint: 65, expected: "A" }, | ||
{ codepoint: 10, expected: "\n" }, | ||
{ codepoint: 61, expected: "=" }, | ||
{ codepoint: 126, expected: "~" }, | ||
{ codepoint: 32, expected: " " }, | ||
{ codepoint: 48, expected: "0" }, | ||
])( | ||
"convert ASCII codepoint $codepoint to ASCII string $expected", | ||
({ codepoint, expected }) => { | ||
expect(codepoint.chr()).toBe(expected); | ||
}, | ||
); | ||
}); | ||
|
||
describe("convert codepoint to emoji", () => { | ||
it.each([ | ||
{ codepoint: 129302, expected: "🤖" }, | ||
{ codepoint: 129412, expected: "🦄" }, | ||
])( | ||
"convert codepoint $codepoint to emoji $expected", | ||
({ codepoint, expected }) => { | ||
expect(codepoint.chr()).toBe(expected); | ||
}, | ||
); | ||
}); | ||
|
||
describe("convert hex codepoint to string", () => { | ||
it.each([ | ||
{ codepoint: 0x404, expected: "Є" }, | ||
{ codepoint: 0x24, expected: "$" }, | ||
{ codepoint: 0x1f303, expected: "🌃" }, | ||
{ codepoint: 0x1f92a, expected: "🤪" }, | ||
])( | ||
"convert hex codepoint $codepoint to string $expected", | ||
({ codepoint, expected }) => { | ||
expect(codepoint.chr()).toBe(expected); | ||
}, | ||
); | ||
}); |
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 if using the extra describe blocks is needed. I'd figured that using describe
blocks is meant to group things up, but since there's only one case for each describe block, then i don't think it's necessary having it. I'd 2x check with @miorel on what he recommends here, if these extra blocks provides more clarity.
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.
Resolved the other comments, but interested to here @miorel thoughts on this. I could go either way.
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.
So I pulled the PR and ran it both with and without the inner describe
s. I don't have a strong preference for whether we keep them or not. I think the main use case for the descriptions is when some tests fails, we want to be clear on which test it was.
The grouping with the inner describe
s is nice when we're running a specific test file, though. If you'd like to keep them my main ask would be to make the strings less redundant with the it
descriptions, and also pass a "noun phrase" to the describe
.
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
workspaces/adventure-pack/goodies/typescript/Number.prototype.chr/index.test.ts
Outdated
Show resolved
Hide resolved
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.
Thanks for working on this! I think it's pretty much ready to go.
it.each([ | ||
{ edgecase: -1 }, | ||
{ edgecase: 11120651 }, | ||
{ edgecase: Infinity }, | ||
{ edgecase: -Infinity }, | ||
{ edgecase: 1.5 }, | ||
{ edgecase: 1e-2 }, | ||
{ edgecase: 0xffffff }, | ||
])( | ||
"handles number $edgecase outside unicode range by throwing range error", | ||
({ edgecase }) => { | ||
expect(() => edgecase.chr()).toThrow(RangeError); | ||
}, | ||
); | ||
|
||
it("handles incompatible types that resolve to NaN by throwing range error", () => { | ||
expect(() => NaN.chr()).toThrow(RangeError); | ||
}); |
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 think NaN
can be merged with the other invalid values.
it.each([ | |
{ edgecase: -1 }, | |
{ edgecase: 11120651 }, | |
{ edgecase: Infinity }, | |
{ edgecase: -Infinity }, | |
{ edgecase: 1.5 }, | |
{ edgecase: 1e-2 }, | |
{ edgecase: 0xffffff }, | |
])( | |
"handles number $edgecase outside unicode range by throwing range error", | |
({ edgecase }) => { | |
expect(() => edgecase.chr()).toThrow(RangeError); | |
}, | |
); | |
it("handles incompatible types that resolve to NaN by throwing range error", () => { | |
expect(() => NaN.chr()).toThrow(RangeError); | |
}); | |
it.each([ | |
-1, | |
11120651, | |
Infinity, | |
-Infinity, | |
1.5, | |
1e-2, | |
0xffffff, | |
NaN, | |
])( | |
"throws RangeError for non-Unicode value %p", | |
(value) => { | |
expect(() => value.chr()).toThrow(RangeError); | |
}, | |
); |
); | ||
}); | ||
|
||
describe("converts hex codepoint to string", () => { |
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.
Hex only exists for the developer's benefit:
console.log(0x1f303); // prints 127747
console.log(0x1f303 === 127747); // prints true
So I'm not sure we gain from having a hex-specific section, it's just another way of writing valid integers.
Imo we can move the 0x24
into the ASCII codepoints test cases (and we'll just have one of the ASCII codepoints written as hex, while others aren't). Likewise we can move the emoji ones into the emoji test, and have some of those codepoints written as hex and some as decimal.
The Є test can either be removed entirely or have its own test (non-ASCII non-emoji?).
Hey @Gobleizer I took this PR as-is since I'm about to work on some changes that might otherwise cause you some merge conflicts. Feel free to do a follow-up with any additional changes from the discussion. Thanks again for working on this! |
Resolves #113.