Excellent kata, but definitely more work than the average 7kyu!

Translation for C++ available.

That's a fair point. I have changed part of the description to match my previous explanation:

"At least 30min (0.5) is needed between each show (in order to make it to the next venue!) This means that if you see a 1 hour long show at 6pm (6), the next possible show that you could see would be at 7:30 (7.5) or later."

Do you feel that is more clear now?

No, as far as I can see you didn't tell at all whether it is inclusive or exclusive.

Hello Oliver,

First of all, thank you for creating this problem. It helped me to practice organizing thoughts into code blocks procedurally one by one.

Is there a way I can please get test inputs for cases when movies start at the same time but prices are different and when movies start at the same time but prices are same?

This is because when I run tests I customized for these cases, I am getting expected results as described in the instructions. However, when I run them here I am failing those cases.

This is true, thanks @kontic! I have changed the description to reflect it!

I'm sorry but I'm not sure exactly what you are asking. Your example seems to fit with what I was trying to describe so maybe my description was unclear?

Yes, your example would work, as the show goes for 1 hour (1), which leaves 30 min (0.5) to get to the next performance. You would in that case be able to see both. If on the other hand, the second show started at 7, you would not be able to make it as there wouldn't be the minimum of 30min buffer time. Is that more clear?

Thanks for your feedback!

What if a show's time is just on the moment you're available to watch another show?

e.g if I watch a show at 6 that lasts for 1 hour, there's a show on 7:30, can I watch the show?

You mean assertDeepEquals is better? Yes, it is.

And then there's comparing floating point values, which should be done with assertApproxEquals ( or a custom wrapper ). Something to keep in mind for the future.

Writing good tests is not easy ( which you found out already ). :]

Note that your reference solution modifies its input (!), so calculating the expected value before the actual ( user ) value would have the effect of always giving the user a presorted input.

Fullproof completely sure would be to calculate the expected answer first, with a copy of the input; the actual answer second, with its own copy of the input, then comparing ( actual, expected ).

This is one of the reasons why I make not modifying inputs a requirement sometimes, test for it seperately, and then have tests that are not vulnerable to input modification, and test the reference solution for not modifying input as well. ( And when possible, I like to have different reference and example solutions. ) JavaScript behaviour just has too many subtleties sometimes; e.g. it's quite easy to forget to copy the element Objects of an Array. Solvers can then still modify every element of their input.

You believe wrong. :P

The fixed tests have predictable answers, so can be hardcoded; the random tests can be modified. It is still possible to satisfy the tests without an actual solution.

I fixed it for you; the correct way is to supply user with a copy of any modifiable object, which in this case is the outer Array as well as every inner Object. [].map returns a new copy of its array argument; Object.assign creates new copies of objects. [...array] would work for an array of primitives; Array.from( a, o => Object.assign({},o) ) would have been nice but is not as transparent.

Thank you!
I was having trouble with assertEquals and didn't realize that assertEquals was much better!
I have also tried to implement all of your other suggestions.