Despite all the people who have passed the tests...

Yep, you've identified the issue. Although technically, we've proven that DECODING should test both -- or at least should test whether, if you have errors in encoding, you have the exact-reverse error in the decoding. :/

OK, Ramunas, I think I get what's going on — it comes down to my test fixture using your own toAscii85 and fromAscii85 methods to figure out what's expected. (And this is clearly not ideal; I hadn't thought about that until now.)

So, when it's testing your ability to decode random binary data, here's what happens under the hood:

1. I generate an array (the decoded array) containing 20 objects that are each 1,000 bytes long and contain random binary data;
2. I run each of the objects through your own toAscii85 method, and store the resulting ASCII85-encoded strings in another array;
3. For each of the objects in the encoded array, I compare the output of encodedObject.fromAscii85() (which is the "my result" value) to the object stored at the corresponding location in the decoded array (which is the "expected" value).

So, looking through what's happening to you, the issue is:

1. What you see as "expected" in the test failures is the correct data — because that's the actual data I'm generating as the input to the test cases.
2. What you see as the input is INCORRECT — and this is generated by your own toAscii85 method, so that's where you should look for the error.
3. What you see as "my result" in the test failures is, technically, correct... for the given input. But since the given input is in error — it's not the proper ASCII85 representation of the original binary data — decoding it doesn't match the original binary data.

Does that make sense?

Ramunas, that's weird — I get the same thing you do, but don't know where my code would expect that result you're saying it does. Did it happen a second time?

Might I suggest then that you give the ASCII85 encoder/decoder kata a try? :)

http://www.codewars.com/dojo/katas/5277dc3ff4bfbd9a36000c1c

Nicely done, and I love the backwards-compatibility shim you added!

Nice kata -- my only comment is that make_process_tree isn't very Javascript-like, where functions are typically camelCased rather than underscore-separated.

More better! :)

I think the kata's ready, but would ask one question: why the weird return string, rather than just returning the converted value itself?

Agreed with the issue that you need to make clear that the value passed to the constructor is a string, both by stating so explicitly and by updating your examples.

Agreed that returning NaN from a toString() call is nonsensical — perhaps it should throw an error, but it shouldn't return a non-string.

Overall, this whole kata feels like an exercise in nonsense; I can't imagine any time when this would be a handy class to have in your toolbelt.

Um, I thought regex was disallowed? At least a handful of the already-submitted solutions use it...

Boom -- Object.getOwnPropertyNames now works as well (http://www.codewars.com/dojo/katas/reviews/52859abdf8fc1b12e0000144/groups/52868629affb2c31a1000cf7). Baffling, though, that it iterates in a different order!

Awesome. I'll try to submit my solution but using Object.getOwnPropertyNames and see what happens!

Your test harness is expecting the keys of the object to appear in the exact same order, which I'm finding is fine with the exception of your random-input test — for some reason, I'm unable to return an object that has the keys in the order you're expecting them. But it leads me to ask: why are you expecting the keys of the returned object to be in any particular order?