Hi René
On 06/03/2024 18:16, René Scharfe wrote:
Hello Phillip,
Am 04.03.24 um 10:51 schrieb Phillip Wood:
On 03/03/2024 10:13, René Scharfe wrote:
TEST_CTYPE_FUNC defines a function for testing a character classifier,
TEST_CHAR_CLASS calls it, causing the class name to be mentioned twice.
Avoid the need to define a class-specific function by letting
TEST_CHAR_CLASS do all the work. This is done by using the internal
functions test__run_begin() and test__run_end(), but they do exist to be
used in test macros after all.
Those internal functions exist to implement the TEST() macro, they
are not really intended for use outside that (which is why they are
marked as private in the header file). If we ever want to update the
implementation of TEST() it will be a lot harder if we're using the
internal implementation directly in test files. Unit tests should be
wrapping TEST() if it is appropriate but not the internal
implementation directly.
forcing tests to be expressions and not allow them to use statements is
an unusual requirement. I don't see how the added friction would make
tests any better. It just requires more boilerplate code and annoying
repetition. What kind of changes do you envision that would be
hindered by allowing statements?
On reflection I don't think I'm objecting to allowing statements, only
the use of the private functions to do so. If we tweak test__run_begin()
and test__run_end() so that the description is passed to
test__run_begin() and we invert the return value of that function to
match what test__run_end() is expecting then we can have
#define TEST_BEGIN(...) \
do { \
int run__ = test__run_begin(__VA_ARGS__); \
if (run__)
#define TEST_END \
test_run_end(run__); \
} while (0)
Which allow test authors to write
TEST_BEGIN("my test") {
/* test body here */
} TEST_END;
The macros insulate the test code from having to worry about
test_skip_all() and the "do { ... } while (0)" means that the compiler
will complain if the author forgets TEST_END. I'm slightly on the fence
about including the braces in the macros instead as that would make them
harder to misuse but it would be less obvious that the test body is run
in its own block. The compiler will allow the test author to
accidentally nest two calls to TEST_BEGIN() but there is an assertion in
test__run_begin() which will catch that at run time.
The slight downside compared to TEST() is that it is harder to return
early if a check fails - we'd need something like
TEST_BEGIN("my test") {
if (!check(0))
goto fail
/* more checks */
fail:
;
} TEST_END;
Also unlike TEST(), TEST_END does not indicate to the caller whether the
test failed or not but I'm not sure that matters in practice.
What do you think?
Best Wishes
Phillip
Ideally we wouldn't need TEST_CTYPE_FUNC as there would only be a
single function that was passed a ctype predicate, an input array and
an array of expected results. Unfortunately I don't think that is
possible due the the way the ctype predicates are implemented. Having
separate macros to define the test function and to run the test is
annoying but I don't think it is really worth exposing the internal
implementation just to avoid it.
The classifiers are currently implemented as macros. We could turn them
into inline functions and would then be able to pass them to a test
function. Improving testability is a good idea, but also somehow feels
like the tail wagging the dog. It would be easy, though, I think. And
less gross than:
Alternatively we could unroll the loop to provide a very long expression
that tests all 256 characters and EOF and hand that to TEST, but that
seems awkward and hard to read.
... which would yield unsightly test macros and huge test binaries. But
it would certainly be possible, and keep the definitions of the actual
tests clean.
René
