Re: [PATCH 6/6] t-strbuf: use TEST_RUN
- From
- phillip.wood123@gmail.com <phillip.wood123@gmail.com>
- Date
- Jul 4, 2024, 13:09 UTC
- Message-ID
- <c2de7f4e-e5dc-4324-8238-1d06795a2107@gmail.com>
- In-Reply-To
- <e4da5c4d-2900-4d62-b855-7c4382a2b949@web.de>
On 02/07/2024 21:55, René Scharfe wrote:
Show 36 quoted lines
> Am 02.07.24 um 17:14 schrieb phillip.wood123@gmail.com:
>> Hi Josh and René
>>
>> On 01/07/2024 20:58, Josh Steadmon wrote:
>>> On 2024.06.29 17:47, René Scharfe wrote:
>>>
>>> I think this commit in particular shows how TEST_RUN() is more
>>> convenient than TEST(). (Although, arguably we shouldn't have allowed
>>> the setup() + callback situation to start with.)
>>
>> I think the counterargument to that is that using TEST_RUN() makes
>> the tests noisier and more error prone because each one has to be
>> wrapped in an if() statement and has more boiler plate initializing
>> and freeing the strbuf rather than getting that for free by calling
>> the test function via setup().
>
> I guess these are two sides of the same coin. Explicit initialization
> and cleanup is closer to what real strbuf users do, more idiomatic.
> Which helps to see what the tests are actually doing.
>
> The wrapping if is less annoying than a wrapping function that I have
> to name and call. The condition is just !ctx.skip_all, though, (for
> now at least) so we could do something like:
>
> #define TEST_START(...) if (!TEST_RUN(__VA_ARGS__)) return test_done()
>
> ... and tests could look like that then:
>
> TEST_START("this and that");
> check(this);
> check(that);
>
> TEST_START("whatever");
> check(whatever);
>
> Perhaps a bit too much magic, though?I think so. It's an interesting idea, but at some point someone will probably want to be able to run a subset of the tests in a file like "--run" does for the integration tests so I don't think we want to assume we can skip all the tests just because any particular test should be skipped.
Best Wishes
Phillip
> René