From: Phillip Wood <phillip.wood123@gmail.com>
Date: Fri, 30 Jun 2023 09:48:50 GMT
Subject: Re: [RFC PATCH 1/2] Add C TAP harness
Message-ID: <7a375796-aadd-a982-430c-a78b27bac59b@gmail.com>
In-Reply-To: <ZJ0cIKrSVmwMy6F4@ugly>

On 29/06/2023 06:52, Oswald Buddenhagen wrote:
> On Mon, Jun 26, 2023 at 02:15:39PM +0100, Phillip Wood wrote:
>> On 21/06/2023 16:57, Linus Arver wrote:
>>> - Make the 'TEST' macro accept the test description first. Or, keep the
>>>    'TEST' macro but also name a new macro 'IT' that accepts the
>>>    description first, to encourage usage that reads in a
>>>    behavior-driven-development (BDD) style, like 'IT("should accept 
>>> foo",
>>>    t_bar(...))'. I find some test descriptions easier to write this way.
>>
>> The test description is a printf style format string followed by 
>> arguments. This allows parameterized tests to include the parameter 
>> values in the description to aid debugging but it means the test 
>> function must be the first parameter. We could have IT("should accept 
>> %d", t(), i) but that would be a bit weird.
>>
> with some minor preprocessor magic [1], you could make that
> 
>    IT(("should accept %d", i), t(i))
> 
> which would be somewhat more noisy, but arguably even somewhat clearer.
> notably,
> 
>    IT("should accept foo", t())
> 
> would still work with the same macro.
> 
> [1] https://stackoverflow.com/a/62984543/3685191

Thanks, I'd not come across that trick before. As you say it is a it 
noisy though.

> somewhat on a tangent: it's also possible to overload macros on argument 
> count [2], which may also come in handy.
> 
> [2] https://stackoverflow.com/a/24028231/3685191

When I was writing my original reply to Linus I did wonder if we could 
count the arguments. I didn't pursue it as I don't really want to create 
a dozen different macros for different argument counts. I think TEST() 
is understandable by anyone reading the code whereas IT() seems a bit 
odd unless one is used to BDD.

Best Wishes

Phillip