Unit tests of internal functions

[Nicolas Williams]

On Tue, Dec 29, 2009 at 11:18:44AM -0500, Greg Hudson wrote:
> On Mon, 2009-12-28 at 15:11 -0500, ghudson at MIT.EDU wrote:
> > 1. Just export those symbols [...]
> > 2. Make those symbols available through the accessor [...]
> > 3. [...] build a second version of each shared library [...]
> > 4. [...] build static versions of each library [...]
> 
> More on this, based on the feedback and my own investigation:
> 
> [...]
> 
> Currently I favor (1).  Sam suggested trying to do things the current
> way before falling back to (1) or (2); I don't particularly like that
> idea because the build system becomes fragile in the face of unrelated
> future work-- when someone changes the C file containing the function
> being unit tested, that can change the set of objects the test program
> needs to link against.

I favor (1).  However, you could do a hybrid of (1) and (3).  Namely,
alter the symbol export list according to whether you're making the
check target.  One would "make check && make clobber && make install".

> I know some developers have concerns about people using internal
> functions if we make it possible to do so.  My experience just doesn't
> back up those concerns.  In my observation, if you label your internal
> functions (as we do with the krb5int_ prefix) and don't prototype them
> in your installed header files, people pretty much won't use them.  In
> the very rare cases where they come up with a good enough reason to do
> so, they will take responsibility for it if it breaks.  Observe that
> very few open source libraries even have a Unix export list.

I agree.

Nico
--