Ad
  • Default User Avatar

    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.

  • Custom User Avatar
    • 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.
  • Custom User Avatar
  • Default User Avatar

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

  • Custom User Avatar

    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;
  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution