Re: [RFC PATCH 0/3] Introduce clar testing framework

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 1, 2024, 09:31 UTC
Message-ID: <ZqtWAvbX9jwYBnWH@tanuki>
In-Reply-To: <xmqq7cd18srf.fsf@gitster.g>

On Wed, Jul 31, 2024 at 08:51:00AM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> >   - The clar gives us the ability to pick which tests to run via command
> >     line parameters, which I personally like more than picking the
> >     specific binary to run.
> 
> One thing I am very unhappy about the current t/unit-tests/ is that
> the GIT_SKIP_TESTS mechanism is not effective at all.  If we can
> wrap clar's test selection syntax inside t/Makefile to work with
> GIT_SKIP_TESTS (or its superset equivalent), that would be a great
> plus.

Yeah, I guess that shouldn't be too hard.

Show 8 quoted lines

> >   - The clar replaces some test assertions that we already have. They
> >     feel a bit more mature, but overall there aren't all that many
> >     assertions available. If we wanted to pick it up, then we'd likely
> >     have to add some more wrappers.
> 
> That is a slight bummer, as importing an externally developed one is
> with the hope that we won't have to enhance or maintain it, but
> we'll see how much burden it will be.

The clar exposes generic helpers like `cl_assert`, but also comparison functions like `cl_assert_equal_$t` for pointers, integers and strings. If anything is missing, it also exposes the building blocks to add project-specific assertions so that it would be easy to add for example `cl_assert_equal_oid`.

One thing I have been missing is non-equality comparisons like `cl_assert_lt_i`/`cl_assert_gt_i`. But adding that to the clar itself and upstreaming it should be easy enough, also because we know the people maintaining it.

Other than that I think it's mostly fine and should serve as a good baseline.

Patrick