Reraised as an issue.

I disagree, eval is only evil when applied on input you don't have full control over.

You define your own operations object which uses only strings you defined, so it's pretty safe. The parseInt on n1 and n2 also makes sure nothing except numbers will come through, so those are safe too.

Either way I wouldn't vote this as best practice, but in this case eval is shorter than a switch and just as safe.

yes

still undefined ? because it's working for me as I speek

Hi, thanks for pointing this out. I have fixed it now.

For this specific case, I fixed the JS kata to use assertSimilar. I'll make sure that Jake is aware of the bug for example test cases (although I believe he is).

@bkaes That makes sense.

It threw me off, since str$ is a very not-JavaScript-like name for a function, and the JavaScript testing library has a built-in Test.assertSimilar method that works fine for Arrays (just not Objects).

Example test cases were copy/pasted from final test cases but i've forgotten to copy/paste …

@ZozoFouchtra: Nah. You haven't forgot anything, your preload code is fine (you can see the preload code if you start a translation). It simply doesn't get preloaded on example test cases.

This bug has been in for about 2 months, so it happened after yout translation. There are several bug reports on this matter, but all apparently most of them just said "It doesn't work sometimes" or "it doesn't work in that specific kata". Since this bug happens almost everywhere nowadays, I added a new bug report. Maybe it isn't a defect, but intended, but I doubt that.

As @bkaes wrote it str$ is just an alias for JSON.stringify.
Example test cases were copy/pasted from final test cases but i've forgotten to copy/paste var str$ = JSON.stringify too (shame on me) !

Users may add it at the start of their test cases, or replace str$ by JSON.stringify.
As the translation is now approved, only the sensei (@cmgerber) may modify the kata.

Isn't str$ not defined a result of the preload-doesn't-work-on-example-test-cases bug? After all, str$ works fine in the regular test cases.

A small workaround would be var str$ = JSON.stringify; at the start of the example test cases.

Yeah, there's some garbage left in there, I assume from the Python version.

Also, referring to "numbers as keys" in the JavaScript challenge really doesn't make sense, simply because JavaScript can't have numbers as keys (anywhere, even arrays, they are basically converted to strings and stored as a hash on the array object!).

Not much can be done about that last part, though, since it's part of the original kata.

I agree with @marutiborker, the existing cycle test won't catch breadth-first searches, only depth-first ones.

boom, done

There is "What about cycles?" test.