An invalid currency type is used as payment or requested as change

Currency type is a enum. This literally shouldn't be happening. If the calling code is intentionally producing invalid enums, that's an abuse of the type system and user code should be be expected to handle that. (Especially since this cannot happen in some other strongly typed languages.)

The kata just assumes that everyone knows what value every note/coin is. What are the values of Quarter, Dime, Nickel and Penny? They need to be clarified.

I think it does not make much sense to limit correct values to 10.

If the input to the function is less than 1, greater than 10, or invalid in any way, return an empty array.

Because of that. Closing.

You should clarify that price and payment are in the same currency (I assumed price was always in US$)
I had lots of troubles to get the right approximation. In the end I got the tests to pass by truncating instead of rounding cents. It doesn't sound reasonable to me. Maybe there is some other error in my code and this strange approximation compensates for it...don't know

Please define in the description how you want invalid input handled, or correct the DecodePangramTest.
That test has a lowercase 'm' in the encoded input. Since no properly coded message can have lowercase, that is invalid input. Analagous to a corrupted zip file.
It's not difficult to work around, but gives the impression of a broken test.

Thanks.

Ah, but there aren't any instructions for decoding. Only for encoding. We are expected to derive the rules for decoding on our own. If you are claiming that rule 1 applies both to encoding and decoding, then perhaps you should state that, because otherwise, seeing it in the same block as a rule that says alpha characters will be shifted toward 'Z' by the alphabetical position of the previous alpha character., which is obviously a rule for encoding, not decoding, implies that they all are encoding-only rules. And when inverting those rules to produce the decoding process, one might easily assume the inverse of a process that transforms everything into capitals (or non-letters) when encoding, is to be able to assume they will always be capitals (or non-letters) when decoding. This is not a huge deal, of course. Plenty of people will trip over that one test case, see what happened, and fix it. But it is an ambiguous "gotcha", and careful reading of the instructions is not sufficient to know that you expect rule 1 to apply to decoding.

there is problem in testRow11 . rowNumber =11 , result is [1, 10, 45, 120, 210, 252, 210, 120, 45, 10, 1] but it give me Failed , but others give True . Please fix it thanks (:

Nice kata! Thanks!

Yep. Thank you. Fixed now.

Looks like instead:

'The function should return an empty array if any of the following conditions are met'

should be:

'The function should return null if any of the following conditions are met'

You're welcome and thanks for the kata. I enjoyed it! :)

i was afraid this might be unclear. I'll reword it when i get a free minute. thanks again

Really nice kata, thank you!

Yes, those errors are gone now. Thanks! There's something in the description that should be changed. It says: "The function should return an empty array if any of the following conditions are met:..." but tests (under TestInvalid) expect null instead of empty string array. Also, for me it's a bit unclear how the price currency is decided. Is it by the paidType?