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?