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