Thanks a lot!

They are useless :
#include <sys/socket.h>
#include <netinet/in.h>

enough : #include <arpa/inet.h>

You can rename the predefined class to Kata and you should be able to submit your solution (if it's correct). But the author should rework his template.

Greetings everyone! Can anyone help understand the error?

symbol: variable Kata

location: class SolutionTest

src/test/java/SolutionTest.java:11: error: cannot find symbol

  assertEquals("a (b c (d e))", Kata.reverseParens("a ((d e) c b)"));
                                ^

In IntlijIdea, I get the right results.

Apparantly not, description needs to be language-agnostic (the removal of function name from the example)

Fixed

fixed by fork above

Javascript Fix

• Node v18 enabled
• Assertion using chai
• Re-created the random tests
• Made the code block in the description language-agnostic (by only using js code block)
• Turns out the ref sol failed to handle when the start of the string is blank parentheses. For example, "()abc(a)def". The ref sol returned "(a)cba()def" instead of the same string. So, ref sol is changed and also added cases like these into edge case.

This is a better place for it.

Random generators and fixed tests should then be updated to include empty strings in all languages.

I think the random generator won't generate empty parens in JS either ( and in Haskell, and possibly in other langauges ).

If the spec is extended to specifically allow empty parens ( which is a good idea! ), the random generators should be checked and possibly updated in all languages.

I didn't want to have to write a custom test function for the sample tests which would have turned out longer than the tests, making it less readable for little gain.

Python tests usually don't need custom assertion messages for non-white kata, since users are expected to know they can print their own inputs if they need them.

That was quick! Initially there were no assertion messages (that is what I was referring to). BTW, I see you've used test.expect instead of test.assert_equals (used in sample tests), though the output differs not much, but maybe it would be wise to unify them (use either one of them and not both)

Fixed.

Though I don't know what you mean by useful assertion messages. Python's assertions are quite unambiguous, if perhaps badly formatted for long outputs. Anyway, fixed that too.