Re: Patch to stop counting missing tests on internal functions

[Rik]

John W. Eaton wrote:
> On 13-Oct-2009, Jaroslav Hajek wrote:
>
> | I would also like to see more private functions become really private;
>
> I would also like to see this happen, but it will mean some changes in
> the build system, and as I'm currently working on converting the
> Octave build system to use automake (I should have something to show
> soon) I'd like to delay any such change until after the automake
> changes are done.
>
> | one problem I see is that a number of __helper__ functions are
> | compiled codes, which are all bundled in one directory in the current
> | Octave's binary files organization.
> | Regarding the test log, it is surely not realistic to expect every
> | source file to have tests; the list in fntests.log includes assistant
> | sources, such as oct-locbuf.cc, for which no test is really
> | meaningful, or even auto-generated sources, such as mx-cm-dm.cc.
> | Maybe C++ files that are expected to have tests some day can be marked
> | as such, and only those files listed.
>
> How about only noting the C++ source files that have DEFUNs?
>   
Maybe we are going about this the wrong way.  The current script
searches for all *.cc and *.m files and then checks whether there there
are any test features (%!test, %!assert, %!error, %!warning) in the
file.  This check is too simplistic and the results are both overly
pessimistic and overly optimistic.  First, they are overly pessimistic
because they seem to show that a lot of files are undocumented, but most
of these files do not contain user functions and instead are helping
code or auto-generated code.  Secondly, they are overly optimistic about
coverage because even a single test for a single function will count the
entire file as being covered.  The file utils.cc has 12 functions in it
and it would be useful to know which ones actually had coverage.

What if we start with the list of functions visible to Octave (using
calls to __builtins__ and __list_functions__) and then cycle through
that list trying to call any test functions?  If there are no tests then
the test function returns something to indicate that and we can mark the
function as needing work.

--Rik
> jwe
>
>