Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby on git

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby on git
Date: 2009-09-26 21:31:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 09/26/2009 02:28 PM, Dan Colish wrote:
> There are a variety of projects dedicated to creating C unit test
> frameworks. I don't have a lot of experience with them, but I have heard
> good things about check and cunit. Here's a link I found with a longer
> list of frameworks.

Looking at check and cunit - I don't see what sort of mock function 
facility they would provide? One part of unit testing is arranging for 
functions to be called, tested, and results reported on. This can take 
you a certain amount of the way. "Pure" functions, for example, that 
always generate the same output for the same input parameters, are 
perfect for this situation. Perhaps test how a qsort() or bsearch() 
method works under various scenarios?

Most real life code gets a little more complicated. For example, what if 
we want to simulate a network failure or "out of disk space" condition? 
What if we want to test out what happens when the Y2038 date is reached? 
This requires either complex test case setup that is difficult to run 
reproducibly, or another approach - "mock". It means doing things like 
overriding the write() method, and making it return successful N times, 
and then failing on the (N+1)th time with ENOSPC. It means overriding 
the gettimeofday() method to return a time in the future. A major 
benefit of this sort of testing is that it should not require source 
changes in order to perform the test. This sort of stuff is a LOT easier 
to do in OO languages. I see it done in Java a lot. I can't remember 
ever having seen it done in C. I think it's just too hard compared to 
the value obtained from the effort.

In your list above, it does show a few attempts - CMock sticks out as a 
for example. It looks more complicated, though. It takes a .h file and 
generates stubs for you to fill in? That could be difficult to manage 
for a large project with thousands or many times more unit tests. OO is 
easier because you can override *only* particular methods, and you can 
safely call the super method that it overrides to provide the underlying 
behaviour in the success cases.


Mark Mielke<mark(at)mielke(dot)cc>

In response to


pgsql-hackers by date

Next:From: Joshua TolleyDate: 2009-09-26 21:35:33
Subject: Re: WIP - syslogger infrastructure changes
Previous:From: Peter EisentrautDate: 2009-09-26 20:02:55
Subject: Re: 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group