git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Jun 7, 2024, 15:00 UTC
Message-ID
<b7eca313-9ea8-4132-ba1d-ed9236e07095@gmail.com>
In-Reply-To
<pull.1677.v2.git.git.1716710073910.gitgitgadget@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:
Show 18 quoted lines
> 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

Show 7 quoted lines
> +/*
> + * 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.

Show 21 quoted lines
> +
>   #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
Show 7 quoted lines
> +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.

Show 14 quoted lines
> +	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

Show 23 quoted lines
> +		.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
Show 42 quoted lines
> +	}), "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
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 12 in “apply: add unit tests for parse_range”
  1. 0/2 apply: add unit tests for parse_rangePhilip Peterson via GitGitGadget, Feb 19, 2024
  2. 1/2 apply: add unit tests for parse_range and rename to parse_fragment_rangePhilip Peterson via GitGitGadget, Feb 19, 2024
  3. Junio C HamanoFeb 19, 2024
  4. PhilipApr 4, 2024
  5. Junio C HamanoApr 4, 2024
  6. 2/2 apply: rewrite unit tests with structured casesPhilip Peterson via GitGitGadget, Feb 19, 2024
  7. Junio C HamanoFeb 19, 2024
  8. Kristoffer HaugsbakkFeb 19, 2024
  9. apply: add unit tests for parse_rangePhilip Peterson via GitGitGadget, May 26, 2024
  10. Junio C HamanoJun 6, 2024
  11. Phillip WoodJun 7, 2024
  12. Junio C HamanoJun 7, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.