On Fri, 24 Feb 2006, Michael Glaesemann wrote:
> [I neglected to cc the list in my reply earlier. Apologies to Gavin
> for the double-post.]
>
> On Feb 23, 2006, at 11:40 , Gavin Sherry wrote:
>
>
> > I do think that unit testing of areas such as data types would be
> > useful,
> > particularly the date/time code and arrays as I consider that area
> > of the
> > code quite fragile. I wouldn't expect the unit tests to find any bugs.
> > Rather, it would make it easier, I think, for people (particularly new
> > comers) to hack on that part of the code with more confidence.
> >
>
> This is the area I specifically had in mind when thinking of unit
> tests. I am looking to do more work on the date/time code in
> particular, and having a unit testing framework and tests to verify
> expected behavior would definitely give me a greater sense of
> security that I wasn't mucking stuff up.
Yes. You sound like the perfect person to implement this :-).
> Your earlier proposal was probably the one I remembered. Could you
> comment on your experience with any of the existing unit testing
> frameworks? In particular, did any stand out in applicability to
> Postgres? What's your take on possible licensing issues?
I looked at Check and CuTest from memory. The former was more
sophisticated, if memory serves me correctly, because it had the ability
to fork and run the code from a child to see if it segfaulted, for
example.
The licensing issue is more of a pain. Obviously we cannot incorporate GPL
stuff into to the code base. CuTest seems to have a pretty BSD compatible
license, though.
That said, the actual implementation is very straight forward: 1) Queue
test functions which assert something about the result of a function 2)
Run the tests 3) capture pass/fails. We have some special requirements
with our code because it can ereport()/elog(). As such, it is quite
attractive to just write our own, if unit testing is to proceed.
Thanks,
Gavin