@JohanWiltink thank you!

@Larissa Have a look. I did for JS what I did for Haskell, mostly. I may have forgotten a failure message here or there, but I think I've done adequate custom messages where the default was not enough ( sometimes it is ).

Thanks Kacarott. I will see again my solution of this kata soon

I'll fix up the JS version some more. I can't do that for Python unfortunately, I don't know enough Python.

There is a difference between 21 and black jack. The test cases are correct. [10, 11] beats [5, 5, 11]

This is stated in the description:
"-Get 21 points on your first two cards (called a blackjack), without a dealer blackjack;"

the message is ok. The "problem" you introduced by solving the "message problem" is that you do 2 calls to the user's function for the same input. If the user is adding debugging stuff to his code, that will make the output panel confusing. So, message is now good, but not the way to fill it. Clearer?

In JavaScript, in the test cases the dealer is not expected to win if both players have the same sum of cards.

Log

Dealer: Jason has the cards: 5, 5, 11
Player: Jimmi has the cards: 10, 11
The total sum of Dealer Jason's cards are 21
The total sum of Player Jimmi's cards are 21
Expected: 'Jimmi', instead got: 'Jason'

Log

Dealer: Frank has the cards: 5, 5, 11
Player: Brandon has the cards: 10, 11
The total sum of Dealer Frank's cards are 21
The total sum of Player Brandon's cards are 21
Expected: 'Brandon', instead got: 'Frank'

@JohanWiltink, Thanks for your help, it was much harder than it seemed at first. I will be grateful to you if you help bring everything to a successful conclusion.

@LarisaOvchinnikova That was not true, I had valid responses and it was not accepting my responses, for now the issue seems to be resolved (with the same script).

Please ask for confirmation that the problem is actually solved before closing issues. You had not solved the issue this user was experiencing. And he really was experiencing an issue.

After factoring out the validation function, it should really also be used for the basic tests. Those are ( still ) a mess.

The JS tests actually did have major problems Larissa. Whenever the expected value was not null one of two wrong tests ( boys and girls count were switched ) failed, was caught, and failed the user solution with a generic failure message.

I've done some cleaning up, and things should more or less work now. It can still be done cleaner.

It can also be used for Example tests if you factor out the checking function, don't use that for null results ( and take that logic out ) and directly test for null when appropriate ( that way you don't give away any logic ). There is no need for a reference solution at all except to give a possible solution on failing tests; I think that should still be put back into the failure messages for the current tests. But I wanted correct tests first.

random tests test your solution and do not check for an exact match with any particular result. In the tests, it is checked that a string of the desired length is created, that the letters G and B are placed in the order that corresponds to the condition of the problem.

( Assuming JavaScript. This sh!t can be language-dependent - it helps if you say in which language you're having an issue. )

That's what it says, but it's not what it does. The real problem is catching the AssertionErrors testing is throwing. You're trying to be too smart, author.