See https://www.codewars.com/kata/562086bbaacc2b4d13000047/discuss/javascript#657d1ac4dc8017ba924dd64e

The migration from the old expect utility to chai introduced this regression. I'm surprised there aren't any safeguards for expect calls that are never completed. There were a few other no-op expect calls that this report uncovered. Thank you.

P.S. I initally reported this comment, because it read like a person just copying their solution into chat. In the future please mark the comment as an issue and reference the submission without publicly pasting the code.

I don't believe this is necissary. The example test is just for developing the algorithm. Everything else in the full test suite (like hint validation) is for cheat prevention and has clear error messages.

Any test case you choose is valid as long as there are two of each color, as mentioned in the description. The example tests are trivial to modify, run, and log/debug.

In the real world you don't always have logging for a production system, and I'm ok with this kata being difficult if that teaches people how to think critically and learn how to write repro tests.

@dfhwze What purpose would that serve? Logging works for user tests.

console.log works fine while testing and is not intended to be available during an attempt. I don't think this is uncommon for sandboxed kata, and it does not appear to violate any of the authoring guidelines.

Errors provide messages and reference the offending line. Combined with the test titles, the information should be sufficient for users to build their own test cases to reproduce any failures.

Resolving due to inactivity.

The droids don't seem to have that information stored in their databanks.

The method signatures do indicate that colors can be arbitrary strings. You never know what strange languages you might encounter on Tatooine.

I added an example to help demonstrate the order of events and API documentation for the class interfaces. I hope that helps. Let me know if you run into any issues. Thanks again for your feedback.

Thank you for taking the time to review this kata.

Coming back to this with fresh eyes, I agree that the description is light on specifics. I put a most of the technical details in the comments of the solution template.

Do you think it would help if I inlcuded pseudo code in the description that outlined the testing procedure and provided an example to demonstrate the event API?

I tried to pass the Droid class using the vm sandbox, which allowed ES6 features again, but for the same reason global state was shared and cheating became trivial.

Instead I inspected the GLOBAL object for functions injected by Babel and passed those into the sandbox. It's super hacky, but it seems to work.

I beleive I have resolved all of your issues. Let me know if you think of anything else.

Thanks for your feedback!