Re: Patch to stop counting missing tests on internal functions

[Jaroslav Hajek]

On Tue, Oct 13, 2009 at 11:56 AM, John W. Eaton <address@hidden> wrote:
> On  9-Oct-2009, Rik wrote:
>
> | Currently when a user runs 'make check' there is a report which shows a
> | large number of files that don't have tests written for them and then
> | invites the user to contribute tests.  On looking through the list,
> | however, there are about 60 functions which are for internal use only as
> | designated by the prefix and suffix "__".   An example is __contourc__.cc
> |
> | My proposed patch to fntests.m would remove these from the report of
> | functions missing tests. (This is *only* about reporting.  If tests for
> | internal functions have been written they would still continue to be
> | run.)  First, if these internal functions need coverage they should get
> | it from tests written by the function which calls them.  In the example
> | given, there is already a test in contourc.m which presumably would
> | catch an error in the internal function.  Secondly, if a user does have
> | a few spare moments to write a test for a function we will get more
> | value for the coding effort if they concentrate on functions that people
> | might use all the time rather than internal ones.
> |
> | Thoughts?  If there are no strong objections I'll apply the patch in a
> | few days.
>
> I'm not sure that we should stop testing all functions named this way.
> The naming scheme was adopted because Octave did not have private
> functions or subfunctions, so the functions with names of the form
> __X__ which really should be private functions or subfunctions should
> be converted.  Then they won't be tested because you can't call
> private functions or subfunctions directly, and we could ensure that
> the test script does not search private subdirectories.  Then we would
> be left with functions that are "internal" in the sense that they do
> something special that is not normally useful for programming, but are
> occasionally used for debugging or some other purpose.  I'm thinking
> of functions like __dump_symtab_info__.
>
> jwe
>

I would also like to see more private functions become really private;
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.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz