So for random test cases, you should definitely look at katas you've solved and see how they implemented random tests into their kata so you get a good idea and a good variety of implementations. You can't really "follow along" with a guide because creating random test cases varies from kata to kata.

For starters, I'll answer your question that you asked in your reply. You need to create a private method of the solution inside of your test cases. So then when you call assertEquals(correct output, user's output), you can just call your private solution method in order to see if the user's solution was correct. Again, look at katas you've solved to get a better idea of this.

For this kata in particular, I would recommend you make an array that keeps a pool of words it can randomly take from instead of just adding empty strings everywhere that isnt't a snark location (just makes it look nicer I suppose). Have some sort of "chance" (maybe like a 9/10 chance?) that there is a snark and insert it into a random location in your array. Then randomly assign integer values into the "Boojumeter" array. For this I would recommend to make it a pretty small bounds in order to ensure that there's a good chance of 0-14 being assigned (so it's not always a Boojum).

I hope this steers you in the right direction, and I hope you continue to author more katas in the future!

• merge conflict (you need to fork this, copy the current description and paste it in the fork's description)
• Java version is outdated, you need to set the fork's version to Java 18

First, I added two new example test cases that should further illustrate the goal of the kata.

Second, I made it more likely to create duplicates, for array sizes >= 50, the range of random inputs is now 1 - size/3. array sizes < 50 is now 1 - size/2. Hopefully this satisfies this issue.

Thank you!

Hi,

The inputs generation must be changed: currently, most of the balloons will have unique sizes which means that some incorrect algo could slip through the random tests rather easily. The range for the sizes should not exceed something like randSize/3, to get a "proper" number of duplicated sizes.

Note: I didn't dig in the two fixed tests, but I storngly doubt they are enough.

Cheers

I fixed the initial solution for Python, thank you for pointing that out! (if you click reset the change should show now)

sample tests: balloons and pops seem to be switched as arguments

Thanks for the suggestion! It's definitely a much cleaner and "professional" way of explaining things. I'll go ahead and change the description.

Nice kata! Just a small description suggestion:

"In pop #4, we pop 4 since there’s only one of each balloon, but it is the highest of them all."

I would replace the bolded part above by the line:

"...since all balloons now have same count (here: 1) but balloon 4 is the highest remaining in the air..."

or something like that - basically, make it clear that the tie-breaker behavior that is being applied at this step is due to the frequency/count criterion given in the Description, not to some previously unmentioned new condition that occurs when there is only 1 of each balloon.

Whoops... fixed now, thanks.

Initial code: Argument order is reversed (freq_stack(balloons, pops) should be freq_stack(pops, balloons)).

Sample tests: from solution import two_oldest_ages should be from solution import freq_stack

I couldn't approve because of merge conflicts in the description so I forked your translation and upgraded the tests to JUnit 5.

C++: 500000 random tests are too many and should be redesigned with a higher probability to expect true.

C++: Failed tests should display the input.