From: Phillip Wood <phillip.wood123@gmail.com>
To: "Kyle Lippincott" <spectral@google.com>, "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Josh Steadmon <steadmon@google.com>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v3 3/7] unit-tests: add for_test
Date: Thu, 25 Jul 2024 10:45:29 +0100 [thread overview]
Message-ID: <0a9fac5d-a8e7-4b4f-a681-878c1efdf488@gmail.com> (raw)
In-Reply-To: <CAO_smVi2rJd5SDMsbbxzFUj28a_1KTgdHMz4DTKMsii+Wt5H_Q@mail.gmail.com>
On 24/07/2024 20:24, Kyle Lippincott wrote:
> On Wed, Jul 24, 2024 at 7:53 AM René Scharfe <l.s.r@web.de> wrote:
>>
> Macros like this require additional cognitive overhead to understand;
> I can't read `for_test ("for_test passing test") check_int(1, ==, 1);`
> and understand what's going on without going and reading the comment
> above `for_test`. Unlike `TEST(<func>, "<description>")`, I can't even
> _guess_ what it's doing. This macro is project-specific, and this
> knowledge has to be attained by everyone wishing to even read this
> code.
As well as the obscure name and oddness of using "continue" to exit a
test early I think having two ways of defining tests also adds to the
cognitive overhead of writing tests as one now has to decide which to use.
As you say below it is not clear to me that the changes in the last
three patches that start using for_test() in our existing tests are an
improvement.
This will be the last comment from me for a while as I'm about to go off
the list for a couple of weeks
Best Wishes
Phillip
> I personally consider the patches that use this to be regressions in
> my ability to read and understand the tests. As an example, one of the
> diff hunks in the strbuf patch (patch #6 in the series) does this:
> - TEST(setup_populated(t_addch, "initial value", "a"),
> - "strbuf_addch appends to initial value");
> + for_test ("strbuf_addch appends to initial value") {
> + struct strbuf sb = STRBUF_INIT;
> + t_addstr(&sb, "initial value");
> + t_addch(&sb, 'a');
> + t_release(&sb);
> + }
>
> But the main simplification in that patch (not using
> `setup_populated`) can be achieved without `for_test`:
>
> + static void t_addch_appends(void)
> + {
> + struct strbuf sb = STRBUF_INIT;
> + t_addstr(&sb, "initial value");
> + t_addch(&sb, 'a');
> + t_release(&sb);
> + }
>
> - TEST(setup_populated(t_addch, "initial value", "a"),
> - "strbuf_addch appends to initial value");
> + TEST(t_addch_appends(), "strbuf_addch appends to initial value");
>
> It seems to me that all `for_test` is getting us there is an inlining
> of the test logic, which seems like it's optimizing for vertical space
> in the file. Maybe it's because I'm coming from a C++ environment at
> $JOB that's using Google's gunit and gmock frameworks, where every
> test is in its own function and we usually don't even write the main
> function ourselves, but I have a preference for the separate
> functions.
>
> Maybe I'm in the minority, so only consider this at somewhere like a
> -0.5 on this series (fine with deferring to a reviewer who is
> significantly in favor of it, but if there aren't any, I'd lean
> towards not landing this).
>
next prev parent reply other threads:[~2024-07-25 9:45 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 15:33 [PATCH 0/6] unit-tests: add and use TEST_RUN to simplify tests René Scharfe
2024-06-29 15:35 ` [PATCH 1/6] t0080: move expected output to a file René Scharfe
2024-07-01 3:20 ` Jeff King
2024-07-01 19:17 ` Junio C Hamano
2024-07-01 22:10 ` Jeff King
2024-07-01 23:38 ` Junio C Hamano
2024-07-02 0:57 ` Jeff King
2024-07-01 19:51 ` René Scharfe
2024-07-01 22:18 ` Jeff King
2024-06-29 15:43 ` [PATCH 2/6] unit-tests: add TEST_RUN René Scharfe
2024-07-02 15:13 ` phillip.wood123
2024-07-02 15:51 ` Junio C Hamano
2024-07-02 20:55 ` René Scharfe
2024-07-02 20:55 ` René Scharfe
2024-07-05 9:42 ` phillip.wood123
2024-07-05 18:01 ` René Scharfe
2024-07-07 7:20 ` René Scharfe
2024-07-08 15:18 ` phillip.wood123
2024-07-08 15:39 ` Junio C Hamano
2024-07-11 15:34 ` Junio C Hamano
2024-07-13 13:27 ` Phillip Wood
2024-07-13 15:48 ` Junio C Hamano
2024-07-08 15:12 ` phillip.wood123
2024-06-29 15:44 ` [PATCH 3/6] t-ctype: use TEST_RUN René Scharfe
2024-07-01 19:49 ` Josh Steadmon
2024-07-01 20:04 ` René Scharfe
2024-07-02 15:14 ` phillip.wood123
2024-07-02 20:55 ` René Scharfe
2024-06-29 15:45 ` [PATCH 4/6] t-reftable-basics: " René Scharfe
2024-06-29 15:46 ` [PATCH 5/6] t-strvec: " René Scharfe
2024-07-02 15:14 ` phillip.wood123
2024-07-02 20:55 ` René Scharfe
2024-06-29 15:47 ` [PATCH 6/6] t-strbuf: " René Scharfe
2024-07-01 19:58 ` Josh Steadmon
2024-07-01 20:18 ` René Scharfe
2024-07-02 15:14 ` phillip.wood123
2024-07-02 20:55 ` René Scharfe
2024-07-04 13:09 ` phillip.wood123
2024-07-10 13:55 ` Phillip Wood
2024-07-14 11:44 ` René Scharfe
2024-07-15 14:46 ` Ghanshyam Thakkar
2024-07-02 17:29 ` Ghanshyam Thakkar
2024-07-02 20:55 ` René Scharfe
2024-07-03 3:42 ` Ghanshyam Thakkar
2024-07-08 18:11 ` Josh Steadmon
2024-07-08 21:59 ` Ghanshyam Thakkar
2024-07-01 19:59 ` [PATCH 0/6] unit-tests: add and use TEST_RUN to simplify tests Josh Steadmon
2024-07-10 22:13 ` Junio C Hamano
2024-07-11 10:05 ` Phillip Wood
2024-07-11 15:12 ` Junio C Hamano
2024-07-14 10:35 ` René Scharfe
2024-07-21 6:12 ` [PATCH v2 0/6] unit-tests: add and use for_test " René Scharfe
2024-07-21 6:15 ` [PATCH v2 1/6] t0080: move expected output to a file René Scharfe
2024-07-23 20:54 ` Jeff King
2024-07-21 6:21 ` [PATCH v2 2/6] unit-tests: add for_test René Scharfe
2024-07-22 19:13 ` Kyle Lippincott
2024-07-22 19:36 ` Junio C Hamano
2024-07-22 20:31 ` René Scharfe
2024-07-22 20:41 ` Junio C Hamano
2024-07-22 22:47 ` Kyle Lippincott
2024-07-23 12:37 ` René Scharfe
2024-07-23 6:02 ` [PATCH v2] unit-tests: show location of checks outside of tests René Scharfe
2024-07-23 13:25 ` Phillip Wood
2024-07-22 22:41 ` [PATCH v2 2/6] unit-tests: add for_test Kyle Lippincott
2024-07-23 7:18 ` René Scharfe
2024-07-23 6:36 ` Patrick Steinhardt
2024-07-23 9:25 ` René Scharfe
2024-07-23 9:53 ` Patrick Steinhardt
2024-07-23 12:37 ` René Scharfe
2024-07-23 13:00 ` Patrick Steinhardt
2024-07-23 13:23 ` Phillip Wood
2024-07-23 13:58 ` René Scharfe
2024-07-23 13:24 ` Phillip Wood
2024-07-25 9:45 ` Phillip Wood
2024-07-30 14:00 ` René Scharfe
2024-07-21 6:22 ` [PATCH v2 3/6] t-ctype: use for_test René Scharfe
2024-07-21 6:23 ` [PATCH v2 4/6] t-reftable-basics: " René Scharfe
2024-07-21 6:24 ` [PATCH v2 5/6] t-strvec: " René Scharfe
2024-07-21 6:26 ` [PATCH v2 6/6] t-strbuf: " René Scharfe
2024-07-23 13:23 ` Phillip Wood
2024-07-24 14:42 ` [PATCH v3 0/7] add and use for_test to simplify tests René Scharfe
2024-07-24 14:48 ` [PATCH v3 1/7] t0080: use here-doc test body René Scharfe
2024-07-24 14:50 ` [PATCH v3 2/7] unit-tests: show location of checks outside of tests René Scharfe
2024-07-24 14:51 ` [PATCH v3 3/7] unit-tests: add for_test René Scharfe
2024-07-24 19:24 ` Kyle Lippincott
2024-07-25 9:45 ` Phillip Wood [this message]
2024-07-25 16:02 ` Junio C Hamano
2024-07-25 21:31 ` Kyle Lippincott
2024-07-26 2:41 ` Junio C Hamano
2024-07-26 12:56 ` Patrick Steinhardt
2024-07-26 15:59 ` Junio C Hamano
2024-07-29 9:48 ` Patrick Steinhardt
2024-07-29 18:55 ` Junio C Hamano
2024-07-30 4:49 ` Patrick Steinhardt
2024-07-30 14:00 ` René Scharfe
2024-07-31 5:19 ` Patrick Steinhardt
2024-07-31 16:48 ` René Scharfe
2024-08-01 6:51 ` Patrick Steinhardt
2024-07-24 14:52 ` [PATCH v3 4/7] t-ctype: use for_test René Scharfe
2024-07-24 14:54 ` [PATCH v3 5/7] t-reftable-basics: " René Scharfe
2024-07-24 14:54 ` [PATCH v3 6/7] t-strvec: " René Scharfe
2024-07-24 14:55 ` [PATCH v3 7/7] t-strbuf: " René Scharfe
2024-07-30 14:03 ` [PATCH v4 0/6] add and use if_test to simplify tests René Scharfe
2024-07-30 14:05 ` [PATCH v4 1/6] t0080: use here-doc test body René Scharfe
2024-07-31 20:52 ` Kyle Lippincott
2024-07-30 14:07 ` [PATCH v4 2/6] unit-tests: show location of checks outside of tests René Scharfe
2024-07-31 21:03 ` Kyle Lippincott
2024-08-01 7:23 ` René Scharfe
2024-07-30 14:08 ` [PATCH v4 3/6] unit-tests: add if_test René Scharfe
2024-07-31 22:04 ` Kyle Lippincott
2024-08-01 7:32 ` René Scharfe
2024-08-02 0:48 ` Kyle Lippincott
2024-07-30 14:10 ` [PATCH v4 4/6] t-ctype: use if_test René Scharfe
2024-07-30 14:10 ` [PATCH v4 5/6] t-reftable-basics: " René Scharfe
2024-07-30 14:12 ` [PATCH v4 6/6] t-strvec: " René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0a9fac5d-a8e7-4b4f-a681-878c1efdf488@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=phillip.wood@dunelm.org.uk \
--cc=spectral@google.com \
--cc=steadmon@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).