Ad
  • Custom User Avatar

    Good point about Set. I've prefixed the test constructor so there's no name conflict.

    I'll also consider changing 'falsy' to null and undefined. Thanks for the feedback!

  • Custom User Avatar

    Good catch. Fixed.

  • Custom User Avatar

    I have added functions into the mix. My apologies if your solution became invalidated.

    I won't add any additional requirements to the kata from now on. (I'll only fix issues, if any come up)

  • Custom User Avatar

    I didn't think random tests would add much (if any) value to this kata so I didn't implement them initially, but I've added them in now that I see that a function with an array of strings passes the normal tests. The new test cases now test a randomized amount of assorted values from an array for each 'type', which should prevent any 'cheesing' like having the function return a set list of expected types.

  • Custom User Avatar

    I did forget the array test. Thanks, added it in.

  • Custom User Avatar

    I really enjoyed this kata. EXCELLENT JOB. The last bomb stumped me for months, though. So here's yet another hint for people, since none of the existing hints helped me enough...

    BOMB 10 HINT:

    If you've already been 'inspecting' the Bomb code, you're on the right path. This is a big clue for the entire kata, but there's more to the final bomb than just that. But do that for bomb 10 and it'll give you a pretty good hint in the form of a comment, which should reveal two tasks you need to complete.

    If you try to diffuse right away, you'll probably get an error (Something like "TypeError: ___ is not defined!"). There's a very good reason for the error, and part of solving the bomb includes ensuring that the error doesn't throw. Find out why the error throws, and you're halfway to solving bomb 10. The other half of bomb 10 solution is kind of similar in approach to some of the earlier bombs, but more complex.

    You can do it! I believe in you!

  • Custom User Avatar

    String(Number(octet)) === octet

    This is perfect. Wish I'd thought of it.

  • Custom User Avatar

    There was an issue with the second and third batch of random tests always displaying the initial board as entirely filled with just 2's. This has been resolved and the actual inital board state is now displayed. Additionally, the description has been updated to state that the updateBoard function must return your answer- simply modifying the input value is not enough.

  • Custom User Avatar

    Thanks for the callout! This restriction was never intended. To remedy this, I've modified the test suite to copy all inputs to the user solution using Array.from() so that the user solution does not have to be a pure function. (If it isn't, it will modify a copied value, which won't harm anything, but also won't solely fulfill the test requirements)

    However, modifying the test suite to take the modified input value into account in addition to the return value would be a lot of effort on my part, so I've updated the description to specifically state that the answer must be returned from the updateBoard function.

  • Custom User Avatar

    After fixing another few issues... (sorry for the wait!) I feel confident that this kata is finally in a good state. If you submitted recently and got an arcane error, please resubmit your code if you still have it.

    I've made the following changes:

    • Fixed a bug with the test's solver. I've manually verified countless randomly generated solutions so my certainty is pretty high this is working as expected now
    • Tuned up the reporting in the test suite so that reports from random tests now read side-to-side to make it much easier to see the test outcome and why the test failed
    • Increased the rigor of the random tests dramatically. Instead of generating 1 random board for each direction, 3 times (a total of 12 assertions) the suite now generates three sets of boards (5, then 20, and finally 100). The user's solution is then validated against the test's solution for every direction (this is HUNDREDS of assertions).
  • Custom User Avatar

    This is likely due to an error in the tests. I am pretty certain I've fixed it now so if your solution works, you shouldn't see this error again.

    Also, I've beefed up the test suite to make its checks more extensive and its reports more readable. Thanks for your comment! Please resubmit!

  • Custom User Avatar

    Ah, there was a copy + paste error in the test! No rotate method should be allowed. Thanks for pointing that out!

    I've fixed the issue, and also beefed up the test suite! Please try resubmitting :)

  • Custom User Avatar

    This is super interesting. I didn't even realize that input modification was possible here, but I was able to trick the test with the initial solution. Each test now receives a copy of the random board for that portion of the test fixture using:
    Array.from(originalBoard)

    instead of a reference to the source board (which the test asserts against, allowing the trick). This should prevent further muddling with the random tests.

    I also modified the test to read from the user's TFE object instead of the fixture's, so now you can modify the direction values to your heart's content :)

    Thanks a lot for your feedback!

  • Custom User Avatar

    After much reworking, the random tests should now be working better. Thanks for the feedback and sorry for the wait!

  • Custom User Avatar

    This is true! There was indeed still an issue. I wrote some additional tests to prove this case and re-worked the solution to meet these tests:

    The previous tests confirmed that the row

    4|#|2|2

    when shifted right, would combine correctly to

    #|#|4|4

    But the solution still combined the row

    2|2|#|4

    incorrectly into

    #|#|#|8

    This has been fixed. Please re-try your solution to confirm, and thanks for the feedback!

  • Loading more items...