Re: Thoughts on unit testing?

On 11 August 2017 at 07:13, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
wrote:

> On Fri, Aug 11, 2017 at 10:35 AM, Andres Freund <andres(at)anarazel(dot)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.)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services