Re: [PATCH v2 2/6] unit-tests: add for_test
- From
René Scharfe <l.s.r@web.de>
- Date
- Jul 23, 2024, 12:37 UTC
- Message-ID
- <0af06e8e-e1d7-4cf6-b968-5dad5f4fef2e@web.de>
- In-Reply-To
- <Zp99icyrc0rdxg9a@tanuki>
Am 23.07.24 um 11:53 schrieb Patrick Steinhardt:
Show 11 quoted lines
> 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?
Show 11 quoted lines
>>> 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é