Re: PostgreSQL unit tests

On Feb 24, 2006, at 13:25 , Gavin Sherry wrote:
>> 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 :-).

:) I'm willing to help out with it. I'd hope to get guidance both in
specifications and implementation. I'd probably need to write unit
tests to test the unit test framework as well, given my lack of C
experience. ;)

> 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.

I thought the forking bit was a definite plus for Check (and GNU
Autounit). I think this would be something we'd like to include.

> 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.

My understanding of the current licensing policy is that if it's not
BSD (even if it's BSD-like), it doesn't go into the distribution. I
don't want to start a huge licensing debate, but that would preclude
using CuTest, which is zlib/libpng according to its homepage, and GPL
according to its Sourceforge site.

> 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.

Rolling our own would definitely get around the licensing issues as
well.

I think it would be worth it to me to have unit tests covering the
date/time datatypes, and I would think hackers working on other
datatypes would benefit from the framework as well. However, this
estimation of "worth" is based from a position of relevant ignorance
on the time investment necessary to get this off the ground. I also
recognize that probably a majority of the backend code would *not* be
easily testable using such a framework. Do others see value in moving
ahead on this? What's the likelihood that a good implementation would
be accepted? Are there others that would be willing to work with me
on this?

Michael Glaesemann
grzm myrealbox com