Re: [PATCH v2] apply: add unit tests for parse_range

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Philip

Thanks for re-rolling, I've left a few comments below

On 26/05/2024 08:54, Philip Peterson via GitGitGadget wrote:
> From: Philip Peterson <philip.c.peterson@gmail.com>
> 
> Also rename parse_range to parse_fragment_range for external linkage.
> 
> Signed-off-by: Philip Peterson <philip.c.peterson@gmail.com>
> ---
>      apply: add unit tests for parse_range
>      
>      Add unit tests for apply's parse_range function. Also rename parse_range
>      to parse_fragment_range and expose it externally for use by the unit
>      tests. Internal callers may continue to refer to it by the name
>      parse_range.
>      
>      It is necessary to make the function be non-internal linkage in order to
>      expose it to the unit testing framework. Because there is another
>      function in the codebase also called parse_range, change this one to a
>      more specific name as well: parse_fragment_range. Also add several test
>      cases (both positive and negative) for the function.

This description is useful and should be part of the commit message 
above the "---" line

> +/*
> + * exposed only for tests; do not call this as it not
> + * a part of the API
> + */
> +extern int apply_parse_fragment_range(const char *line, int len, int offset,
> +				      const char *expect, unsigned long *p1,
> +				      unsigned long *p2);

We don't bother with extern on function declarations as can be seen from 
all the other declarations in this header file.

> +
>   #endif
> diff --git a/t/unit-tests/t-apply.c b/t/unit-tests/t-apply.c
> new file mode 100644
> index 00000000000..0eb0c22fc0d
> --- /dev/null
> +++ b/t/unit-tests/t-apply.c
> @@ -0,0 +1,101 @@
> +#include "test-lib.h"
> +#include "apply.h"
> +
> +#define FAILURE -1
> +
> +typedef struct test_case {
> +	const char *line;
> +	const char *expect_suffix;
> +	int offset;
> +	unsigned long expect_p1;
> +	unsigned long expect_p2;
> +	int expect_result;
> +} test_case;

We don't use typedef's in this code base

> +static void setup_static(struct test_case t)
> +{
> +	unsigned long p1 = 9999;
> +	unsigned long p2 = 9999;
> +	int result = apply_parse_fragment_range(t.line, strlen(t.line), t.offset,
> +						t.expect_suffix, &p1, &p2);
> +	check_int(result, ==, t.expect_result);

If we expect apply_parse_fragment_range() to return an error then I'm 
not sure we want to bother checking p1 and p2 as I don't think we make 
any guarantees about their values in that case. If we promised not to 
touch them unless the fragment was successfully parsed we would want to 
check that but we don't make that promise.

> +	check_int(p1, ==, t.expect_p1);
> +	check_int(p2, ==, t.expect_p2);
> +}
> +
> +int cmd_main(int argc, const char **argv)
> +{
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,4 +",
> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = 9,
> +		.expect_p1 = 4,
> +		.expect_p2 = 4
> +	}), "well-formed range");

This is a nice use of compound literals. It would be good to have a test 
that checks .expect_result for a longer input string to ensure we're not 
just stopping at the end of the string.

> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4 +8 @@",

I would be nice to vary "-4" a bit, all the tests where the parse is 
successful expect p1 == 4

> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = 7,
> +		.expect_p1 = 4,
> +		.expect_p2 = 1
> +	}), "non-comma range");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -X,4 +",
> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 9999,
> +		.expect_p2 = 9999
> +	}), "non-digit range (first coordinate)");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,X +",
> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 4,
> +		.expect_p2 = 1 // A little strange this is 1, but not end of the world

This is an example of why I don't think we should check p1 and p2 when 
we're expecting the parse to fail. Also please note we don't use "//" 
comments in the code base.

There is a good range of failing non-digit inputs. It would be nice to 
see a test for a hunk header where the number is too large to parse. 
Ideally we'd also change the parsing code to return an error in that 
case rather than waiting to error out later on as the apply code does 
currently. To do that You'd need to explicitly set errno to zero before 
calling strtoul() and check it afterwards.

Overall this is looking pretty good, thanks for working on it

Best Wishes

Phillip


> +	}), "non-digit range (second coordinate)");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,4 -",
> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 4,
> +		.expect_p2 = 4
> +	}), "non-expected trailing text");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,4",
> +		.offset = 4,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 4,
> +		.expect_p2 = 4
> +	}), "not long enough for expected trailing text");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,4",
> +		.offset = 7,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 9999,
> +		.expect_p2 = 9999
> +	}), "not long enough for offset");
> +
> +	TEST(setup_static((struct test_case) {
> +		.line = "@@ -4,4",
> +		.offset = -1,
> +		.expect_suffix = " +",
> +		.expect_result = FAILURE,
> +		.expect_p1 = 9999,
> +		.expect_p2 = 9999
> +	}), "negative offset");
> +
> +	return test_done();
> +}
> 
> base-commit: b9cfe4845cb2562584837bc0101c0ab76490a239