On Fri, Apr 26, 2024 at 2:26 AM Linus Arver via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
>
> From: Linus Arver <linusa@xxxxxxxxxx>
>
> Test the number of trailers found by the iterator (to be more precise,
> the parsing mechanism which the iterator just walks over) when given
> some some arbitrary log message.
s/some some/some/
> We test the iterator because it is a public interface function exposed
> by the trailer API (we generally don't want to test internal
> implementation details which are, unlike the API, subject to drastic
> changes).
>
> Signed-off-by: Linus Arver <linusa@xxxxxxxxxx>
> +static void run_t_trailer_iterator(void)
> +{
> + static struct test_cases {
> + const char *name;
> + const char *msg;
> + size_t num_expected_trailers;
> + } tc[] = {
...
> + };
> +
> + for (int i = 0; i < sizeof(tc) / sizeof(tc[0]); i++) {
> + TEST(t_trailer_iterator(tc[i].msg,
> + tc[i].num_expected_trailers),
> + "%s", tc[i].name);
Nit: the members of struct test_cases are used in the (msg,
num_expected_trailers, name) order, while they are declared in the
(name, msg, num_expected_trailers) order. I think it would make it a
bit easier to use in struct test_cases the same order in which they
are used in the TEST() macro.
> + }
> +}
> +
> +int cmd_main(int argc, const char **argv)
> +{
> + run_t_trailer_iterator();
> + return test_done();
> +}
LGTM otherwise.
