EDIT: for Straights with an Ace, only the ace-high straight is accepted. An ace-low straight is invalid (ie. A,2,3,4,5 is invalid). This is consistent with the author's reference solution. ~docgunthrop

Upon revisiting poker rules more, wheels are generally considered to be allowed in Texas Hold'em. So disallowing this would make the game NOT Texas Hold'em. This needs to be fixed in the kata.

The reference Solution in Scala tests looks damn smart, but it doesn't bloody work.

hand("List(6♠, 5♥)", "List(6♦, 7♣, 7♥, 8♦, 8♥)") should return "(straight,List(8, 7, 6, 5))"
hand("List(8♣, 6♣)", "List(6♦, 8♦, 9♣, 7♥, 7♠)") should return "(straight,List(9, 8, 7, 6))"
hand("List(9♠, J♣)", "List(8♣, J♠, 9♥, 8♥, 10♥)") should return "(straight,List(J, 10, 9, 8))"

The sliding(5) is the culprit here, it doesn't ensure that the size is actually 5 if the list is of size 4 or less. Which can happen quite easily, actually. I happened to make a similar mistake myself, and it passed without notice as there are no fixed tests to check similar conditions, and it can only be spotted by random tests for "three-of-a-kind", "two pair" or the fully random ones. Which is 250 tests, and still by far not enough.

You talk about paths from a to b being oneway streets, yet you only mention somewhere deep in the comments that multiple such streets may exist between a and b.
Several of the issues/questions logged by users are a result of you neglecting/refusing to update the description. As you state so yourself, you are "too lazy" to do so.
My friend Joe would say, "Oh, c'mon man!"

Python translation don't test the full house with two triples case (at least not intentionally).

To filter out wrong solutions which return 'three-of-a-kind' on two triple cases, I think something like this should be added.

• Case: ['3♠', '3♥'], ['3♦', '4♠', '4♥', '4♦', '2♣']
• Expected: 'full house', ['4', '3']
• Wrong answer examples: 'three-of-a-kind', ['4'] or similar, 'full house', ['3', '4']

I'm not sure whether the Python translation includes the similar test (listed below) or not, but even if they don't, I think it's okay not having them since these are relatively unlikely to be missed.

• 'four-of-a-kind' with a 'three-of-a-kind': ['3♠', '3♥'], ['3♦', '4♠', '4♥', '4♦', '3♣'], Expected: 'four-of-a-kind', ['3']
• 'full house' with two possible 'two pair's: ['3♠', '3♥'], ['3♦', '4♠', '4♥', '5♦', '5♣'], Expected: 'full house', ['3', '5']
• 'two pair' with three 'pair's: ['3♠', '3♥'], ['A♦', '4♠', '4♥', '5♦', '5♣'], Expected: 'two pair', ['5', '4', 'A']

Edge cases should be explicitly tested, e.g.:

• full house with 2 ranks having 3 repetitions
• full house with 1 rank having 3 repetitions and 2 more ranks having 2 repetitions each
• two pair with 3 ranks having 2 repetitions
• flush with more than 5 cards with the same suit
• etc.

50 random tests is way too little for such task.

C# translation ready for review.
I'm generating 10000 random hands to provide enough variations of types of hands. Let me know if this is ok or whether rare types (4 of kind, straight flush, ..) should have a bias.

No sample tests!

The fourth test case is wrong. The correct path is [0, 56, 99] and the total driving time is 8. Please fix the test.

I'm having trouble passing the fourth test case, it seems like the answer is incorrect (though I have difficulty believing that since other people have passed it). I get the path [0,56,99] (cost of 8) and the answer is [0,56,12,66,99] (cost of 18), I've manually checked and both paths are valid, obeying one way roads (my original implementation made all roads two way which gave me this problem on the third case).

Is there some part of the description I am missing? I don't want to invest further time in this if it's a buggy test case.