From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros) |
Date: | 2019-10-06 02:20:38 |
Message-ID: | 20191006022038.GB4023404@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sat, Oct 05, 2019 at 12:07:29PM -0700, Andres Freund wrote:
> +#define EXPECT_EQ_U32(result_expr, expected_expr) \
> + do { \
> + uint32 result = (result_expr); \
> + uint32 expected = (expected_expr); \
> + if (result != expected) \
> + elog(ERROR, \
> + "%s yielded %u, expected %s in file \"%s\" line %u", \
> + #result_expr, result, #expected_expr, __FILE__, __LINE__); \
> + } while (0)
> ...
>
>
> I wonder if we should put these (and a few more, for other types), into
> a more general place. I would like to have them for writing both tests
> like regress.c:test_atomic_ops(), and for writing assertions that
> actually display useful error messages. For the former it makes sense
> to ERROR out, for the latter they ought to abort, as currently.
>
> Seems like putting ASSERT_{EQ,LT,...}_{U32,S32,...} (or Assert_Eq_...,
> but that'd imo look weirder than the inconsistency) into c.h would make
> sense, and EXPECT_ somewhere in common/pg_test.h or such?
Sounds reasonable. For broader use, I would include the expected value, not
just expected_expr:
elog(ERROR, \
"%s yielded %u, expected %s (%u) in file \"%s\" line %u", \
#result_expr, result, #expected_expr, expected, __FILE__, __LINE__); \
I didn't do that for the atomics tests, where expected_expr is always trivial.
The codebase has plenty of Assert(x == y) where either of x or y could have
the surprising value.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-10-06 16:06:40 | pgsql: Avoid trying to release a List's initial allocation via repalloc |
Previous Message | Andres Freund | 2019-10-05 19:07:29 | expressive test macros (was: Report test_atomic_ops() failures consistently, via macros) |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-10-06 02:22:01 | Re: New "-b slim" option in 2019b zic: should we turn that on? |
Previous Message | Alvaro Herrera | 2019-10-05 22:43:33 | parallel restore sometimes fails for FKs to partitioned tables |