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é
