From: Josh Steadmon <steadmon@google.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Phillip Wood <phillip.wood123@gmail.com>,
Achu Luma <ach.lumap@gmail.com>,
git@vger.kernel.org, chriscool@tuxfamily.org,
christian.couder@gmail.com, me@ttaylorr.com,
phillip.wood@dunelm.org.uk
Subject: Re: [Outreachy][PATCH v5] Port helper/test-ctype.c to unit-tests/t-ctype.c
Date: Tue, 16 Jan 2024 21:37:09 -0800 [thread overview]
Message-ID: <ZadnhRtYfrFeMCbX@google.com> (raw)
In-Reply-To: <41cf1944-2456-4115-a934-aff2306a26e5@web.de>
On 2024.01.16 20:27, René Scharfe wrote:
> Am 16.01.24 um 16:38 schrieb Junio C Hamano:
> > Phillip Wood <phillip.wood123@gmail.com> writes:
> >
> >> Thanks for adding back the test for EOF, this version looks good to me.
> >
> > Thanks. Let's merge it to 'next'.
>
> OK. I'm still interested in replies to my question in
> https://lore.kernel.org/git/a087f57c-ce72-45c7-8182-f38d0aca9030@web.de/,
> i.e. whether we should have one TEST per class or one per class and
> character -- or in a broader sense: What's the ideal scope of a TEST?
> But I can ask it again in the form of a follow-up patch.
>
> René
I think that the scope of a TEST() should tend small: we want the
minimal amount of setup required to test the invariants that we're
interested in. For this particular unit test, since we're just testing
simple predicates on static sets of characters, I would be OK seeing one
TEST() per class/character. That would certainly make this unit test an
outlier in the number of checks, but I'm less worried about that since
this is testing system-provided functions that we don't expect to change
regularly.
Additionally, the elimination of a level of macro indirection makes this
more readable IMO.
prev parent reply other threads:[~2024-01-17 5:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 23:15 [PATCH] Port helper/test-ctype.c to unit-tests/t-ctype.c Achu Luma
2023-12-26 18:45 ` Junio C Hamano
2023-12-27 10:57 ` Christian Couder
2023-12-27 11:57 ` René Scharfe
2023-12-27 14:40 ` Phillip Wood
2023-12-27 23:48 ` Junio C Hamano
2023-12-28 16:05 ` René Scharfe
2024-01-02 18:55 ` Taylor Blau
2023-12-30 0:09 ` [Outreachy][PATCH v2] " Achu Luma
2024-01-01 10:40 ` [Outreachy][PATCH v3] " Achu Luma
2024-01-01 16:41 ` René Scharfe
2024-01-02 16:35 ` Junio C Hamano
2024-01-05 16:14 ` [Outreachy][PATCH v4] " Achu Luma
2024-01-07 12:45 ` René Scharfe
2024-01-08 22:32 ` Junio C Hamano
2024-01-09 10:35 ` Phillip Wood
2024-01-09 17:12 ` Junio C Hamano
2024-01-12 10:27 ` [Outreachy][PATCH v5] " Achu Luma
2024-01-15 10:39 ` Phillip Wood
2024-01-16 15:38 ` Junio C Hamano
2024-01-16 19:27 ` René Scharfe
2024-01-16 19:45 ` Christian Couder
2024-01-16 19:52 ` Junio C Hamano
2024-01-17 5:37 ` Josh Steadmon [this message]
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=ZadnhRtYfrFeMCbX@google.com \
--to=steadmon@google.com \
--cc=ach.lumap@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=me@ttaylorr.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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).