"ChwLA=" can also be umambiguously encoded as "ChwL", and "DC=" as "DC".

Now do you believe it is possible to encode the same array in multiple ways, by abusing the ambiguous ending?

Note that I could also have given you "ChwLAA=", or "DC_=".

DC= means D => 4 bits encoding so there is no confusion possible as we have 6 bits of length, C means 00 00 11, result is [0] (the = could be safely ignored)
ChwLA= => 3 bits
hwLA => 100 001 110 000 001 011 000 000
=> could be [4, 1, 6, 0, 1, 3, 0, 0] but as we have the = flag,
we know we could remove the trailling zeros so the real result is [4, 1, 6, 0, 1, 3]
So the = as a real meaning in this case here to differenciate [4, 1, 6, 0, 1, 3] from [4, 1, 6, 0, 1, 3, 0] or from [4, 1, 6, 0, 1, 3, 0, 0]

How would you decode "ChwLA=" ? Or "DC=" ?

Yes exactly, that’s why when you said "wouldn't it just be fun if non-ambiguous endings could be encoded the same way ambiguous endings have to be?" it doesn’t seem to be possible !

Isn't there a '=' at the end if there are bits to be taken off?

Hello @Johan Wiltink

Indeed, I could remove the requirement of empty string when we have an empty array in the encoder !

We could encode non-ambiguous endings the same way as ambiguous when the last chunk is not exactly 6 bits, but when it does, we need a flag (or a way) to determine if we have to remove last bits or not at decoding time, how else would you do it ?

Your decoder accepts single character inputs and correctly decodes them to empty lists. But you still require [] to be encoded to "" explicitly.

You're still missing a great opportunity to allow for different valid encodings of the same input here.

I still haven't checked, but wouldn't it just be fun if non-ambiguous endings could be encoded the same way ambiguous endings have to be?

I added random testing, thank you for pointing this out !

Thank you for your reply @Johan Wiltink !

I’ve updated the kata according that, now random tests are using the decoder to check for idempotent and it’s working fine :)

Thank you for this suggestion !

talking about the validation tests, where I should write tests which use the decoder to validate the idempotence of the solution ?

Exactly that. I meant you should write a decoder, not solver.

It would of course be possible to have solver write a decoder as well. The beauty of having solver write an encoder and a decoder is that you only need either a reference encoder or a reference decoder to test both. :]

Hello @JohanWiltink and thank you for all your great feedback!

I’m not sure to understand perfectly your comment about decoder, do you mean the kata should be focus on decoding instead of encode, or should it be on decoding and encoding, or you’re talking about the validation tests, where I should write tests which use the decoder to validate the idempotence of the solution ?

I would actually suggest to write a decoder and test by generating inputs, let solver encode them, decode the result, and compare the final result to the original input.

I haven't figured out if disambiguating the trailing part can always be done by one method or the other, but I wouldn't discount the possibility that that could work. If so, it should be allowed, and it would add one more possibility for multiple different correct answers.

All of that can be handled by decoding encoded values.

You’re goal is to write the encode function.

^* Your

The base64 link in the description is wrong.

From the example tests:

it(should return an empty string with an empty array, () => {

This is unspecified. Any valid single character Base64 string should decode to an empty list.

You can require it, but then you should specify it - whch means in the description, not in the example tests.