From: Phillip Wood <phillip.wood123@gmail.com>
Date: Tue, 23 Jul 2024 13:23:44 GMT
Subject: Re: [PATCH v2 2/6] unit-tests: add for_test
Message-ID: <55857c83-2181-4dcb-b354-f9f7e77cd6b9@gmail.com>
In-Reply-To: <0af06e8e-e1d7-4cf6-b968-5dad5f4fef2e@web.de>

On 23/07/2024 13:37, René Scharfe wrote:
> Am 23.07.24 um 11:53 schrieb Patrick Steinhardt:
>> On Tue, Jul 23, 2024 at 11:25:29AM +0200, René Scharfe wrote:
>>> Am 23.07.24 um 08:36 schrieb Patrick Steinhardt:
>>>> There is of course some magic involved with how we generate the file.
>>>
>>> It requires magic function names and generates code using a different
>>> language, while for_test is a just single new control flow keyword,
>>> like the dozen or so we already have.  So the magic employed by the
>>> libgit2 system is both broader and deeper.
>>
>> It is broader, that's certainly true. But it feels more self-contained,
>> less fragile and easier to read to me compared to macros.
> 
> In which ways can for_test break?

Using a "break" statement to exit the test early will exit the loop 
without calling test__run_end()

Best Wishes

Phillip

> 
>>>> But I think that would be quite manageable, and ultimately all that the
>>>> developer would need to care about is writing a `test_foo_something()`
>>>> function. Everything else would be handled by our infra.
>>>
>>> With for_test all the developer has to do is write a test with a
>>> description, no extra infrastructure beyond the existing unit test
>>> framework needed.
>>
>> True, but it feels like it is an invitation for writing unidiomatic
>> code to me. Unidiomatic in this context to me mostly means code that is
>> not self-contained and thus cannot be run standalone.
> 
> Partly this is intentional -- I want to do something that the current
> idiom (the TEST macro) doesn't allow.
> 
> It's possible that reducing friction will cause more sloppy tests to
> be created.  I hope that the bad parts will stand out more when
> there's less boilerplate code.
> 
> René
>