Well, turns out this kata is now a duplicate of https://www.codewars.com/kata/647d08a2c736e3777c9ae1db (integer partition with an upper limit) with a slight difference (subtracted a specific value from the end result).

Related to the issue below: The author didn't actually write a solution that can pass any input in the given range in time, and in fact, for the current input range the kata is impossible to be solved in time, since the complexity is at least O(n * w * h).

The tests are very weak: all random tests have at most w = 10, fixed tests go as much as w = 16, and all tests with bigger w is always full so a trivial solution exists.

Expect(ConstructNum(4, 5)).To(Equal(int64(61)))

I can find 81 with just 3 digits:

10109, 10909, 10919, 19019, 19109, 20209, 20909, 20929, 29029, 29209
30309, 30909, 30939, 39039, 39309, 40409, 40909, 40949, 49049, 49409
50509, 50909, 50959, 59059, 59509, 60609, 60909, 60969, 69069, 69609
70709, 70909, 70979, 79079, 79709, 80809, 80909, 80989, 89089, 89809
90109, 90209, 90309, 90409, 90509, 90609, 90709, 90809, 90909, 90919
90929, 90939, 90949, 90959, 90969, 90979, 90989, 91019, 91909, 91919
92029, 92909, 92929, 93039, 93909, 93939, 94049, 94909, 94949, 95059
95909, 95959, 96069, 96909, 96969, 97079, 97909, 97979, 98089, 98909
98989

It is extremely unclear what the actual specs are from the description.

There are 12 cases

You should have random tests ( those 12 might be random, but I doubt it .. ), and more than 12. Please see documentation.

You may consider unpublishing while you read the docs, while having insufficient test coverage - it may prevent your kata getting downvoted for it.

Please try to get someone to proofread everything. There are innumerable spelling and grammar errors.

Both m and n are in range [3, 25) or [3, 100), vary among languages.

"Vary among languages" is not informative, and you've just reintroduced this issue. Can you stop making these dumb changes which fix/break everything back and forth?

Tips: Input sum >= 0.

assertEquals(false, CrossSum.check(3, 3, -1)); (Java)
assert.strictEqual(cross_sum_check(3, 3, -1), false); (JavaScript)

Since when is -1 >= 0?

The order of the tested values should be randomized.

Input validation is a worthless requirement. Especially, when you're testing only 2 invalid inputs: -1 and 631.

assertEquals(figureMin(x), actual);
assertEquals(x, ds);

If the user's solution is wrong, the second test will never be executed, and even if it was, it's completely useless anyway. - well, maybe knowing that the actual digit sum is wrong might help you to some degree, but seeing how the actual result is different from the expected value is still infinitely more useful. If you want to mention this info for some reason, it should only happen in a custom error message.

It is possible to easily hardcode everything based on error messages without implementing anything.

Duplicate.