Skip to content

Conversation

HoussamLh
Copy link

Self checklist

  • I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
  • My changes meet the requirements of the task
  • I have tested my changes
  • My changes follow the style guide

Changelist

Understanding how to validate ranks strictly (not accepting "0002" or "0x02" as valid numbers).

Deciding whether to use explicit checks vs regex for number cards.

Finding the balance between writing enough tests vs not writing 52 individual card tests.

Making tests more generalised (by category) instead of repetitive.

Questions

  • Is my regex approach (/^[2-9]$/) the right level of strictness for checking number cards, or would you prefer a different method?

  • For the tests, is it better to keep them category-based with a few examples (as I’ve done), or would it be valuable to also include a loop over all possible ranks (2–10, J, Q, K, A)?

  • Should I also test different suits systematically (♠, ♥, ♦, ♣), or is one suit per category enough since the suit doesn’t affect value?

  • Is the error handling message "Invalid card rank" clear enough, or would you recommend more specific errors (e.g., "Unsupported card format" vs "Invalid rank")?

  • Would using a map/dictionary (e.g., {A:11, J:10, Q:10, K:10}) for ranks be cleaner than multiple if statements, or is the current approach acceptable for this task?

HoussamLh and others added 29 commits June 17, 2025 23:30
Added comments to exclude instructional lines from execution.
Updated age variable to let to allow incrementing its value
Declare variable before using in template string.
Add comments explaining slice error and fix by converting number to string
…umerator cases

and add stretch scenarios for isProperFraction edge case testing
- Return proper suffixes for 1st, 2nd, 3rd, and others (e.g., 4th, 11th, 23rd)
- Added Jest tests for various edge cases including teens (11th-13th)
- Improved function to handle general inputs dynamically
- Added str and count parameters to repeat function
- Used String.repeat to repeat str count times
- Throws error if count is negative
- Added tests for count = 1, 0, and negative values
- Updated 3-get-card-value.js to reject invalid ranks like "0002♠", "0x02♠", and "2.1♠"
- Simplified logic with explicit checks for A, J, Q, K, 10, and digits 2–9
- Updated 3-get-card-value.test.js to group tests by categories:
  • Ace → returns 11
  • Number cards (2–10) → return their numeric value
  • Face cards (J, Q, K) → return 10
  • Invalid ranks → throw "Invalid card rank"
@HoussamLh HoussamLh added the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Sep 9, 2025
- Added tests for repeat() covering:
  • repeating a string multiple times
  • returning empty string when count is 0
  • throwing error when count is negative
- Cleaned up unused code to follow best practices
@LonMcGregor LonMcGregor added the Review in progress This review is currently being reviewed. This label will be replaced by "Reviewed" soon. label Sep 10, 2025
Copy link

@LonMcGregor LonMcGregor left a comment

Choose a reason for hiding this comment

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

Good start on this sprint's tasks, I have spotted a few areas where you could improve code further

A few of your files contain merge conflicts. I've left a comment on the first one for you to look at. I can't review those files further until those issues are resolved.

Great questions! I've left comments at the relevant places within your code.

@@ -8,11 +8,19 @@
// Then, write the next test! :) Go through this process until all the cases are implemented

function getAngleType(angle) {
<<<<<<< HEAD:Sprint-3/1-key-implement/1-get-angle-type.js

Choose a reason for hiding this comment

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

Here, where the file contains lines marked between <<<<<< HEAD and >>>>>>> COMMIT_HASH there is a merge conflict. Do you know what this means? Can you spot the problem that will happen if you commit files containing conflicts?

Copy link
Author

Choose a reason for hiding this comment

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

hello LonMcGregor,

Thank you for your feedback and I'm sorry about the conflicts marks. I should not commit files with these markers because the code will break:

  1. The <<<<<<<, =======, >>>>>>> lines are not valid JavaScript.
  2. Your program will throw syntax errors if run.
  3. also signals that the conflict hasn’t been resolved, which can confuse your team.

}



Choose a reason for hiding this comment

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

Did you mean to commit all these blank lines?

Copy link
Author

Choose a reason for hiding this comment

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

hello LonMcGregor,

Thank you for your feedback and I'm sorry about the blank lines. I should not commit file with all this blank lines.

throw new Error("Denominator cannot be zero");
}

return Math.abs(numerator) < Math.abs(denominator);

Choose a reason for hiding this comment

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

Does this correctly handle all cases? What about negative improper fractions?

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thank you for the comment!

After checking, the function already handles negative improper fractions correctly because it compares the absolute values of the numerator and denominator. This way, whether the numerator or denominator is negative, the function still correctly determines if the fraction is proper.

I also included a check for denominator === 0 to avoid division by zero.

expect(getCardValue("10♥")).toEqual(10);

// You can even loop for efficiency:
for (let i = 2; i <= 10; i++) {

Choose a reason for hiding this comment

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

for Question 2: When testing, it is most important to test two things: a sample of normal data and edge cases. For something simple like this you could loop over everything, but that would not be a good idea, or even be possible for a more complex task. In a comment I see you mention efficiency. what does efficiency mean here? Is repeating the same action many times (looping) efficient?

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thank you for the feedback!

  • I see now that looping over all number cards isn’t necessarily the most efficient approach in testing. Efficiency in this context means covering a representative sample of normal data and edge cases, so we get confidence that the function works correctly without making tests unnecessarily long or harder to debug.

  • I’ve revised the tests to focus on representative normal values (2, 5, 10) rather than looping over all number cards. This way we still test important cases while keeping the tests clear, easy to read, and maintainable. Edge cases like Ace, face cards, and invalid cards are still covered.

if (rank === "10") return 10;

// Explicit check for number cards (2–9 only, no leading zeros or decimals)
if (/^[2-9]$/.test(rank)) {

Choose a reason for hiding this comment

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

for question 1: Regex works in these cases, but you will be limited to testing a single digit, which means you need that separate condition for 10.

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thank you for the feedback!

I updated the regex to ^(?:[2-9]|10)$ so it now matches all number cards from 2–10 in a single condition. This removes the need for a separate check for "10" while still correctly handling Ace, face cards, and invalid cards.


// Case 4: Invalid cards
test("should throw an error for invalid card rank", () => {
expect(() => getCardValue("Z♣")).toThrow("Invalid card rank");

Choose a reason for hiding this comment

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

for question 3: The goal of testing is to try and cover all possible goal branches. If you have sufficient sample of possible input, possible known bad inputs, and edge cases, that's enough. Do you think you have achieved that?

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thank you for the feedback!

I’ve updated Case 4 to include a representative sample of invalid inputs, including invalid letters, decimals, leading zeros, empty strings, and suit-only inputs. This ensures the error branch is thoroughly tested and all possible invalid card scenarios are covered.

return Number(rank);
}

throw new Error("Invalid card rank");

Choose a reason for hiding this comment

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

for question 4: The goals of error messages are to inform the user of some code when a problem occurs. If you were using this code and you saw this error, would you understand what it meant? If so, the error is good enough.

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thanks for the feedback!

I see that error messages should be clear to the user. I could improve this one by including the invalid card value in the message, so it’s immediately obvious what caused the error and makes debugging easier.


if (!rank) throw new Error("Invalid card rank");

if (rank === "A") return 11;

Choose a reason for hiding this comment

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

for question 5: a map/dict would also work, but might be a bit overly complicated for this task. My personal preference is if something can be done in 1-3 lines that's usually sufficient. If you had many more possible options, like if each of the 52 cards in the pack had a different rank, then you might consider a different structure. But this is fine.

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thanks! I agree — for a small set of card ranks, the current approach is simple and readable. Using a map would work, but for this task it would be unnecessarily complicated. I see that for a larger set of unique ranks, a map would be a better choice.

// Calculate the sum of all digits and check if greater than 16
const sum = cardNumber.split('').reduce((acc, digit) => acc + Number(digit), 0);
if (sum <= 16) {
return false;

Choose a reason for hiding this comment

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

Because this is the final step in the code, do you need to use an if(condition) { return false} return true structure, could you simplify this, or is it fine as it is right now?

Copy link
Author

Choose a reason for hiding this comment

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

Hello LonMcGregor,

Thank you for the feedback!

I realized the if statement isn’t necessary here because sum > 16 already evaluates to a boolean. Returning it directly makes the code simpler and easier to read.

@LonMcGregor LonMcGregor added Reviewed Volunteer to add when completing a review with trainee action still to take. and removed Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. Review in progress This review is currently being reviewed. This label will be replaced by "Reviewed" soon. labels Sep 10, 2025
@HoussamLh HoussamLh added Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. and removed Reviewed Volunteer to add when completing a review with trainee action still to take. labels Sep 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants