Fixed.

Done, switched to markdown. Thanks for the feedback.

Description should use markdown instead of HTML. For section titles you can use ## h2 headers or ### h3 headers and lower (I do not like h2 because I think they are too big, but you can pick whichever you prefer), <br> is a double trailing space, <p> is supported directly by markdown as newline-separated paragraphs.

Got it!

A couple more:

• @Order does not work without the method orderer or the class orderer annotation. See the collection of examples I linked in the initial post, or JUnit documentation on @Order.
• The Group class has the problem of overriding equals, but not hashCode, which is wrong. In general, the whole class with getters, setters, overrides, constructors, could be brought down to just a single line of public record Group(int size, int timeTaken) {}. Compiler automatically generates constructors, accessors, stringifiers, and equality for records.
• string += elem in tablesToString and queueToString is a really bad pattern. It should be a StringBuilder or a joiner, or both should be ditched in favor of/implemented on top of Arrays.toString.
• rand should be private. You might also want to consider ThreadLocalRandom instead (but I don;t remember if it is that important in context of CW kata).

This should be fixed now. Thank you!

This should be fixed now!

Thanks for checking and for your feedback! Hope this kata is alright then :)
I've fixed the things to do with tests in your original comment. I also don't like how its a int[2] element for queue, but was worried that changing it to include a preloaded class might make it harder to be translated to a different language in the future. I'm fairly new to OOP so I actually didn't know about records but it looks super handy for this use case so I will try it out.

Some kata on similar topic, but I think presenting not exactly similar problem:

• Supermarket queue
• Barista Manager
• Barista problem

I do not remember any problem which would require processing a queue with the additional constraint of minimal required capacity.

Do you know which kata it is similar to? I tried to find any that already exisited before making this but didn't see anything super close.

This might also be a duplicate, or at least very similar to an existing kata.

• Java tests should use JUnit 5.
• You have two groups of random tests in one test method. Why not just split them into two separate test methods: small random tests, and large random tests?
• Tests with small inputs (fixed tests and small random tests) could be improved by making them easily debuggable. For example, Assertion messages could present inputs on failure.
• I personally do not like the int[2] as elements of queue, I would make it into a preloaded record Group(int count, int time).

You can check out the authoring examples collection for some ideas.

Very minor feedback- there is a small typo in the description:

they do not know hot to calculate the time properly -> they do not know how to calculate the time properly