Please check my fork. The issue of many tests expecting 0 is because the available ingredients are not guaranteed to include the ingredients from the recipe. This seems to be the case in Python and maybe other languages as well. Anyway, I did fix it by making sure that half the time the available ingredients include a random sample from the recipe. "half the time" can be easily modified to be any other desired fraction.

• limits.h should be climits
• common includes should not be included via Preloaded snippt, they should be present in every snippet which needs them
• Sample tests, Assert::That(actual, Equals(exp), "example #1"); - custom messages do not work this way. They should be provided with ExtraMessage (see here) or similar message supplier. Interesting fact, random tests got this right :) They are also not really necessary in example tests, maybe just remove them.
• Randomly generated tests could be balanced a bit better. Currently, ~40 out of 50 random tests expect 0.

Oh you're right :facepalm:

*(const int*)a - *(const int*)b; is subject to underflow though, so it's not safe to compare large int with that expression

Issues:

• Solution function must return not only a pointer to the allocated buffer, but also its length (possibly by an output param). Currently tests assume that size of the returned buffer is equal to the expected one. If a user solution allocates too small buffer, tests will crash or experience some other kind of UB.
• Expected memory management scheme should be specified, possibly as a comment in solution setup.
• input arrays should be const (i.e. const int* arr1 and const int* arr2). Currently, the user solution and reference not only destroy inputs (which is kind of a nonsense for this kind of task, as this kind of problem can be perfectly solved just by reading values without modifying them), but also they get in a way of each other, because a user solution is called first, it potentially modifies the input array, and then the reference solution is called with destroyed arrays.
• assertion messages are not very helpful. At least failure messages of fixed tests could present inputs.
• stdio.h is not necessary.

Suggestions:

• cr_assert(actual, "the actual value cannot be NULL"); can be cr_assert_not_null(actual, "the actual value cannot be NULL");
• the _compare_ints could be just return *(const int*)a - *(const int*)b;