Ad
  • Custom User Avatar

    Alright. Thank you for approving.

  • Custom User Avatar

    I'm learning to document everything I do and explain it in a way that a wide range of audiences can understand, even those who don't understand anything about programming, so it may seem like I write like an AI. By the way, I've already seen it, everything is correct. Thanks for your contribution.

  • Custom User Avatar

    I fixed the discrepancies mentioned in the translation. If you approve of it, you can navigate to it and hit "approve" to merge it with your kata.

    Just a question — do you speak with GPT? No judgment, but I have never seen that before.

  • Custom User Avatar
  • Custom User Avatar

    Here are a couple of points to consider:

    Misleading Test Description in Random Tests for Invalid Inputs: In the random tests for invalid inputs, the description currently reads "Should return true for random invalid inputs." This is misleading because for invalid inputs, the test should clearly indicate that false is expected. Adjusting this description will help clarify the intended behavior.

    Stylistic Aspects: Although using string.find is perfectly acceptable for verifying the input format, some might prefer string.match as it can enhance readability when simply checking for a pattern match. This is a matter of style and does not affect the correctness of the solution.

    These points are relatively minor, but addressing them can improve the clarity and overall quality of your test suite.

  • Custom User Avatar

    Hello,

    I wanted to let you know that I have completely remodeled the test suite structure based in my own design and your valuable feedback. I stand by my approach:

    Fixed edge cases: I still include tests for specific valid DNIs (like "00000001R" and "99999999R") so that the expected behavior is crystal clear.

    500 Random Tests: I intentionally kept 500 random tests (for both valid and invalid cases) because it dramatically lowers the risk of a solution passing by pure chance. In many similar katas, fewer random tests allow some candidates to pass accidentally by playing around with random inputs, which is something I wanted to avoid.

    Clear error messages: I’ve refined the assertion messages so that every failure clearly states what the result was versus what was expected.

    If you’re curious, feel free to take a look at the complete test suite.

  • Custom User Avatar

    An easy going one of them to be honest, sort of like an entry level kata of the binary trees series, funny nevertheless.

  • Custom User Avatar

    approved, thank you!

  • Custom User Avatar
  • Custom User Avatar

    Under testLettersOutsideValidRange(), you state that "12345678Z" should return false in the error message, but assert that is true (of which is the correct assertion). Slight discrepancy, nothing severe.

    500 valid and invalid random tests is overkill. 40 each should suffice, but even that is pushing it a little. Again, not severe.

    Besides that, all of your fixed tests are for false assertions. I would reccommend adding some fixed tests that expect true to be returned.

  • Custom User Avatar
  • Custom User Avatar

    Remark below is an ISSUE.

  • Custom User Avatar

    Tests are susceptible to input mutation: if I change the input arrays, the changes are reflected in logs and messages.

  • Custom User Avatar

    Random tests are not strong enough. An inferior algorithm, hardcoding 2 fixed tests, made me pass all random tests.

  • Custom User Avatar

    To be fair, I did write the Road class, so of course I know how it works. I imagine that figuring out what it does and how you can use it raises this kata to a 6kyu. I think that it is a fair rating :)

  • Loading more items...