Hi,
On 2017-08-11 09:53:23 +1200, Thomas Munro wrote:
> 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[1] 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).
Yea, I think there's little chance for something like that. The amount
of infrastructure you need to link in and initialize is prohibitive imo.
> 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.
What's your definition of boilerplate here? All the "expected" state
tests in C unit tests is plenty 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[2]. 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.
You can already kinda avoid that in various ways, some more some less
hacky. I think it depends a bit on which scenarios we want to test. How
much infrastructure do you want around? Do you want to be able to start
transactions? Write to the WAL, etc? One relatively easy way would be
to simply have a 'postgres' commandline option (like we already kinda
have for EXEC_BACKEND style subprocesses), that loads a shared library
and invokes an entry point in it. That'd then be invoked at some defined
point in time. Alternatively you could just have a bgworker that does
its thing at startup and then shuts down the cluster...
Greetings,
Andres Freund