Updated the test organization, imported codewars_test instead of implicitly (which was deprecated since Python 3.8), and added assertions for only using digits and "()-=/" and 3 operators to the random tests.

Does this apply to translations too? (can I use integers?)
Right now the open C++ translation uses floats, and the Python random tests use a less-than-epsilon type comparison for supporting float imprecision. If it's really not supposed to use intermediate floats, shouldn't it use the // operator in Python instead of the float / operator?

There we go, I switched it to give the expected length as an argument so it's as easy as other languages while still allowing bounds checking if you want.

Good point with the static!

aligned_alloc should allow the memory allocator to choose not to align it on the maximum struct alignment but instead a multiple of the alignment you specify. I had specified 1 because a char* string is made of bytes, but I'm pretty sure an alignment 4 or 8 would be easier for optimized library string handling functions to deal with.

I removed the preallocation instead.

A mix of both options would be to pass the expected length as a second parameter, so that the user doesn't need to calculate it themselves.

• every function in the test suite should be static
• what's the added value of aligned_alloc() over malloc() here ?
• i'm not sure about using an output buffer when the size of the output is not trivial to compute at all. though it would make the C version more difficult i would prefer users to return their own heap-allocated string and figure out how much memory they need by themselves. I don't like when C kata pass to the user a buffer whose size is not known by the user in advance. it creates more opportunities for confusion and out-of-bounds writes. what do you think ?

Looks good to me!

a minor change might be to switch from mapM_ to forM_ so that the list isn't at the end of the line, and it would also let you avoid those parentheses

Honestly, readability and maintainability are more of a concern to me than coverage, considering that for the default 100 tests, there's a ~99.97% chance that all 10 numbers are tested at least once.

For the sake of completeness, I've changed it to guarantee full coverage.

QuickCheck is fine, but there are only 10 cases, so exhaustive testing is better than entirely random for this.

QuickCheck has a shuffle function of its own that you should probably use instead of an Arbitrary instance -- this would allow you to both ensure that all cases are tested and in a random order to prevent order-sensitive code from working.

The following changes have been made:

• Tests now show input upon failure
  • Fixed tests are labeled in their own corresponding it blocks
  • Random test inputs are shown on failure per QuickCheck's property
• Exports qualified in setup code
• Random tests overhauled
  • Tests now use QuickCheck, which handles test running and random input generation
  • Inputs are generated along with the expected answer, removing the overhead of comparing against a reference solution

Fixed it by matching on the character values (like c >= '0' && c <= '9')

I'm hesitant to approve given the pending issues with the kata which apply to all translations.

Your reference solution returns True for the following strings:

"𤦢g"
"½abi4"
"kQ傗DP3"

because isAlphaNum is based on the Unicode category of the character.

it's usual to say both the user's answer and the expected result

Otherwise it looks good!

Fixed.

why did you use "strin" instead of "str" or "string"?
i suggest using the whole word 'string' when it's reasonable

more importantly, why do the tests repeat so much code? you should write a function, macro, or template so it's easier to read and maintain