On Fri, Aug 11, 2017 at 10:35 AM, Andres Freund <andres@anarazel.de> wrote: > On 2017-08-11 09:53:23 +1200, Thomas Munro wrote: >> 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...
I mean close to zero effort required to create and run new tests for primitive C code. Just create a .test.c file and type "TEST(my_math, factorial) { EXPECT_EQ(6, factorial(3)); }" and it'll run when you "make check" and print out nicely tabulated results and every build farm member will run it.
The closest we come now is a src/test/modules/ with an extension that exposes SQL functions that in turn run the C tests, one SQL func per C test.
Definitely not brief and simple. But that's what I've been doing.
Lots of those unit frameworks support auto-generation of harness code. I wonder how practical it'd be to teach them to generate an extension like this and the .sql to run it?
It won't work if you want to test anything static or file-private, but pretty much nothing will.
(Side note: I'd really like to get away from relying so heavily on 'static' and move toward higher level visibility (https://gcc.gnu.org/wiki/Visibility: -fvisibility=hidden and __attribute__((dllexport)) ). It'd make it easier not to forget needed PGDLLEXPORTs, let us hide stuff we consider really internal but still share across a few files, etc.)
