Hi hackers, 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). 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[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. Thoughts, better ideas? [1] https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C [2] https://github.com/google/googletest/blob/master/googletest/samples/sample1_unittest.cc -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
