Yeah my code doesn't assure that this mix of "text", "number" always occurs, it just "goes" with whatever input has, just raised the issue because I thought this rule was a rule that the tests always followed. Thanks for clarification 🙏

it is stated that text and numbers alternate, which it does not do in your output

it is however a problem that the tests don't consistently catch that

JS test gen does not obey given constraint:

Following this rule, each number tested begins with encoded text and ends with an encoded number.

After the text, there is a binary number.

Testing for '1051209811098120113115108121126110981198106105112122117981198116102108124981001000010010098114110120119108101121111114116'
It should work for random inputs too - Expected: 'et, 6, tmohuzj, 3, felvq, 3, pbhx, 9252, njtshauknp', instead got: 'et, 6, tmohuzj, 3, felvq, 3, pbhx, 9252'

expected answer ends in text, it should end in a number

Ruby as well:

expected: "opbkrfrpk, 542, toixqsrtx, 4, hfvzzgyiuy, 344, uvr, 7, krrk"
     got: nil

(compared using ==)

and Crystal:

Expected: "stxaifmr, 6, zqnigbynah, 6425, albief, 1098, etmf, 788, gxxbuyvc, 84, uksexpybwkyei"
     got: nil

It's your solution. Your solution fails on inputs where encoded text could also be a binary number, and you can see it in the output of the test that you included. Expected: 'wrqjvi, 0, dubb, 13, j... Your solution produced: instead got: 'wrqjvi, 0, dubb, 13, 6..., notice that you have two numbers in a row? Because j is 110, which can also be interpreted as a binary number. Your solution will fail on similar tests, you can add this to the sample tests: Test.assertEquals(decode('1011011011019800110110'), "aaa, 54"); to see it failing in real time.

You just got lucky when you resubmitted your solution and the tests didn't generate a case like this one. The random tests might need to be hardened to make sure to include a "tricky" case like this, but as it is, there is nothing going "wrong" with the tests.

Really fun kata, just a minor issue with a random test.
I don't have the best solution ever but I encountered a random test that my code fails (49/50 tests worked), one resubmit did the job to register my code as a valid solution.

Raising an issue as I don't have a clue if this test breaks a declared constraint of the kata or it's just my solution.
Test:
Testing for '12311811711012210998098104121102102981101981109811000101000001109811612510310511411111910711598100100100010101019811810112511711810498100110011101198119105110120111104104981101111110001111' It should work for random inputs too - Expected: 'wrqjvi, 0, dubb, 13, j, 50438, pycenksgo, 74837, rayqrd, 4923, sejtkdd, 57231', instead got: 'wrqjvi, 0, dubb, 13, 6, 50438, pycenksgo, 74837, rayqrd, 4923, sejtkdd, 57231'.

Description should be language-agnostic (perhaps only modify it after the Haskell translation below has been reviewed && approved

Enabled in this fork

Haskell translation

Approved.

python new test framework + new version is required. updated in this fork

Ruby 3.0 should be enabled.

Yes, great. I updated the description a bit earlier, hope you don't mind.

Cheers

OK, if that is what you meant, I updated the instructions accordingly.

I meant to specify in the instructions that there may be '98's at the very end of the long number that you are decoding, and that sometimes there aren't. That part is intentional (and I'll fix it), however, the '98' should always be separating the binary component and the encoded text.

The use of 98 as a separator is not consistent (at least in python). Sometimes you have it at the end of the number, sometimes not. I don't know if it's intended, but it should be corrected or specified.