Heya! Fun kata, but I ran into a few problems.
Your reference solution has a left -> right bias in terms of parsing the string.
Eg. peelPairs('12251', 6):

• Working l->r: the answer is 221. Total distance between the pair characters (1, 5) is 3. This is the result the reference produces.
• However, r->l: the answer is 122. Total distance between the pair characters (1, 5) is 1, they're adjacent. This is closer than the acceped solution, but will not be accepted.

Given that the instructions state they should be paired with the closest digit to them that sums to n, I think you should clarify the instructions to include closest digit **to the right** of them that sums to n.

Hopefully that makes sense :D

Thanks, the empty string should now no longer occur as a key or value.

Good catch, now both random and fixed tests should be the correct way around.

Thanks, test results should now be the right way around.

Can confirm it's fixed, was just investigating this myself and it suddenly started passing the test cases.

Ahh, I replied in the wrong place XD My reply is above.

Sure thing. All of the test cases are from the random tests, here are some examples:

• nextTrain("00:24", 276) => Expected: 'The next train is at 5:30.', instead got: 'The next train is at 5:00.' 00:24 + 4h 36m = 5:00 arrival.
• nextTrain("23:36", 481) => Expected: 'The next train is at 5:00.', instead got: 'The next train is at 8:00.' 23:36 + 8h 1m = 7:37 arrival.
• nextTrain("10:15", 225) => Expected: 'The next train is at 14:30.', instead got: 'The next train is at 14:00.' 10:15 + 3h 45m = 14:00 arrival.

Hope this helps. Also don't trust my submitted solution, I've already found a bug in it whilst analysing these test cases :D

Hey! I really enjoyed doing this kata. Just a few issues:

• I'm still gettting some random test cases expecting the previous train.
• The instructions state to given results in hh:mm format, but also give the example output of The next train is at 5:00., without a leading zero. I think you should clarify this.

Good kata, just a few bugs to fix:

• Instructions state the result string should be Player[i] wins!. The sample unit tests check for this format: Playeri wins!. The actual unit tests check for this format: Player i wins!.
• Having both players set to attack : 0 causes an infinite loop. If you want this edge case to be part of the puzzle, the instructions should indicate how to deal with it.
• Some unit tests that should end in mutual death expect a player to win. This is becuase you're testing player.health == 0, rather than player.health <= 0. Player health can be negative too.