The current regression tests, isolation tests and TAP tests are very
good (though I admit my experience with TAP is limited), but IMHO we
are lacking support for C-level unit testing. Complicated, fiddly
things with many states, interactions, edge cases etc can be hard to
get full test coverage on from the outside. Consider
src/backend/utils/mmgr/freepage.c as a case in point.
I guess we could consider the various xUnit systems for C and have
an entirely new kind of test that runs independently of PostgreSQL. I
guess that'd be difficult politically (choosing external project,
cognitive load) and technically (global state problems as soon as you
get away from completely stand-alone components).
One idea that keeps coming back to me is that we could probably extend
our existing regression tests to cover C tests with automatic
discovery/minimal boilerplate. Imagine if you just had to create a
file bitmapset.test.c that sits beside bitmapset.c (and perhaps add it
to TEST_OBJS), and in it write tests using a tiny set of macros a bit
like Google Test's. It could get automagically sucked into a test
driver shlib module, perhaps one per source directory/subsystem, that
is somehow discovered, loaded and run inside PostgreSQL as part of the
regression suite, or perhaps it's just explicitly listed in the
regression schedule with a .sql file that loads the module and runs an
entry point function.
One problem is that if this was happening inside an FMGR function it'd
be always in a transaction, which has implications. There are
probably better ways to do it.
Thoughts, better ideas?
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: