Unit tests of internal functions
Ken Raeburn
raeburn at MIT.EDU
Mon Dec 28 18:01:54 EST 2009
On Dec 28, 2009, at 15:11, ghudson at MIT.EDU wrote:
> 1. Just export those symbols, as we do in a number of cases already.
Exporting more symbols increases library size and reduces performance,
though not a great deal in any individual case. It also adds the
possibility of an application either calling the function directly, or
interposing its own version of the function, both of which I think it
would be good to prevent. (And if we want to allow interposition, we
should discuss which functions can be replaced, and when we should
call the externally visible and replaceable versions of functions
versus internal, non-exposed ones, from other library routines.)
> 2. Make those symbols available through the accessor. I would
> personally find this annoying, but it's a valid option. This only
> really helps us in libkrb5, not for other libraries. (We have
> libk5crypto symbols available in the accessor, but it's kind of silly
> since they currently have to be exported from libk5crypto to
> accomplish that.)
We could make a crypto-library accessor as well. The accessor is
awkward to use directly, but a helper file could be generated to
simplify things. (E.g., by defining static function pointers or
functions or macros such that "foo()" in the test winds up actually
calling internal function foo via the accessor.)
> 3. During make check, build a second version of each shared library
> with no restricted export list, and link test programs against that.
Or at least a much larger export list, including all the functions to
be tested.
> 4. During make check, build static versions of each library and link
> test programs against that. Zhana raised the objection that shared
> libraries should be tested as shared libraries, but I think that's
> only important for system tests (like the ones we have in
> tests/dejagnu), not unit tests.
Also relevant for performance testing, since PIC register use will
affect register allocation, etc. It also affects the handling of
initialization/finalization code; system tests should catch most
problems, but we might want to add tests someday to look for problems
specifically in that code.
None of the options look particularly pretty, but in the interest of
testing something that most closely resembles the code to be
installed, I think I'd favor #2 or #3...
Ken
More information about the krbdev
mailing list