[AbdennourHachemi]

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

Task code

CYF-1060

[valentina-starr1]

Thanks for working on this..The core exercise implementations look solid overall, but i can see one blocking issue regarding version control configuration that needs to be addressed before merging.

1. .gitignore Fix (Blocking)
   practice-tdd/.gitignore: Please remove package.json and package-lock.json from .gitignore. These files must be tracked in the repository to maintain consistent dependencies, scripts, and build environments across machines.

2. Actionable Improvements & Refactoring
   practice-tdd/repeat-str.js: Returning an error string ("Error! negative counts...") on negative inputs differs from idiomatic JS and the exercise intent. Please throw an Error instead (e.g., throw new Error(...)) and update repeat-str.test.js to use expect(() => ...).toThrow().

practice-tdd/get-ordinal-number.js: The regex logic works, but switching to numeric modulo operations (num % 100 and num % 10) would make the branching much clearer and easier to maintain.

practice-tdd/get-ordinal-number.test.js: Consider adding test cases for 3-digit teen exceptions (e.g., 111, 112, 113) to ensure the suffix rules scale properly.

practice-tdd/count.test.js: Minor nit - @jest/globals imports aren't needed since Jest provides them globally, and there's a small typo in numberOfOcurrence (numberOfOccurrence).

Once package.json and package-lock.json are un-ignored and the error-throwing behavior is updated, this should be good to go.

[AbdennourHachemi]

Thanks @valentina , i have fixed my code according to your review . please have a look again and see if anything else needs correction.

[hey-hammad]

Great implementation overall, a couple minor issues needs attention. Thanks

[hey-hammad]

a .gitignore file already exist in the root of the repo which is enough.

[hey-hammad]

a test case handling the special cases like 11,12,13,101 & 103 will make this suit more robust.

[cjyuan]

Implementation is correct.

Some of the tests could be refined.

[cjyuan]

• Could consider testing multiple samples in each test category - higher chance to detect bugs in code.

• Empty string is often a good edge case to test.

• When a specification is ambiguous, programmers may need to make reasonable assumptions based on their understanding of the requirements. In this case, the original specification did not explicitly state whether character matching should be case-sensitive. Although most people would likely assume that it is, adding test cases can help document this assumption and make our interpretation of the specification explicit.

  Similarly, we should consider adding tests for any other assumptions made during implementation to clarify the intended behavior and ensure these assumptions are consistently understood and validated.

[cjyuan]

Are all "other digits" covered in this category?

[cjyuan]

• The test description seems incomplete.

• When a comment repeats information already conveyed in the test description, consider removing it to avoid redundancy.

[cjyuan]

In TDD, the test description (or test name) should clearly explain what behavior the function should exhibit.
The goal is that someone reading the test can understand the requirement without reading another spec.

A common format is: should <expected_behavior> when <condition>.

Could you also include the "condition" part into the description?