Ok, so I'd rather keep the current phrasing as it is and simply require the return type to be a list of length 2. I may be wrong, but I think the dicussion around this is becoming too academic. So, I think it's ok if I mark as resolved.

Thank you for the comment. For my response I'd like to clarify that I'd like to learn and understand the norms and best practices. So, I understand what you are saying. However, I responded earlier to the issue raised by hobovsky below. They suggested that "returns a pair of integers" is ambiguous and so I changed the problem specification to "list of length 2 of integers", and added tests to test that. It seems to me now that you are suggesting that I should revert back to the previous ambiguous specifiation and only test for deconstructability into two components. I would highly appreciare further input here as to what is a better solution between these two apparently confilicting suggestions. Thanks in advance.

Thank you very much. I can't believe I missed that typo for so long.

Thank you. I added a test to accept a list of length two and updated the description accordingly. I'm now not getting any terrible crashes on weird outputs.

Solved.

I'm marking as resolved in order to re-publish improvements. I also think the two kata are significantly different, so the issue is actually resolved.

That is true, the large numbers are fixed, but why is that an issue? I'm happy to build randomness if needed, I'd just like to understand the motivation.

I just checked again. I see 227 tests in total.

I reduced the number of tests according to all suggestions made. Much appreciated.

Corrected. Thanks.

Done. Thank you.

I see your point. I'm trying to figure out though if there is a reason to reduce the number of tests. Is there any harm in having the current set of tests? Any gain in reducing it?

I see what you mean. I added a test case to explicitly test for correct behaviour of cyc_func(a) for values outside of the given list a. Thank you for spotting this missed test.

I could have provided n to cyc_func too, but instead I chose to let the cycle determine the value for n, i.e., n is the maximal element in the list. So the specification for cyc_func does determine the output uniquely from the input. So, I'm not quite sure why this is an issue. The baheviour of cyc_func(a) is entirely determined by the input list a: the specification clarifies what the output must be for any 1 <= x <= max(a). What happens on values not in this range is not important (and not tested). (In a strongly typed language I could have specified the domain of cyc_func(a) to be $\{1, \dots, n\}$, but this is Python.)