bugGNU Octave - Bugs: bug #38776, Tests in private functions cannot...

 
 

bug #38776: Tests in private functions cannot be tested directly

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 19 Apr 2013 11:01:56 AM UTC
   
 
Category:  Test Suite Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Wont Fix Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Wed 17 Sep 2025 07:22:47 PM UTC, comment #7: 

I agree with Rik's reasoning in comment #5, and in fact it is more or less option #3 in my original post, and also more or less JWE's stance here:
https://lists.gnu ... -04/msg00414.html.

Note that this bug report was a little nudged by Debian dev(s) who were unhappy with Octave's handling of tests in private subdirs - I had no issues there myself.  IIRC at the time this subject had already been brought up before in mailing lists etc.

On a related note: the io package still has (commented out) tests in private functions. I'll probably remove those long time obsolete tests in a next release; they'd be still in the repo for archeological purposes.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 17 Sep 2025 04:08:00 PM UTC, comment #6: 

This bug was kept open to avoid that the test in isosurface.m is being marked as a regression.
If you prefer to close this report, please remove or adapt the test in that file.

Markus Mützel <mmuetzel>
Group administrator
Wed 17 Sep 2025 03:14:05 PM UTC, comment #5: 

This bug is super old.  The standard that has developed is that private functions should be tested from the user-visible functions that depend on them.  This makes sense to me, a private function can have all sorts of things wrong with it, but if it does the one thing it is supposed to then the rest doesn't matter.

If you really want to have tests of a private function in the function itself then you could use 'oruntests private/ on the private directory to run all of the BIST tests embedded in the private functions.

Marking as Won't Fix and closing report.

Rik <rik5>
Group administrator
Thu 24 Nov 2016 11:35:25 PM UTC, comment #4: 

It is still not possible in 4.2.0

Juan Pablo Carbajal <juanpi>
Group Member
Wed 12 Jun 2013 12:19:59 PM UTC, comment #3: 

We seem to be talking at cross purposes.

I do not worry about how to test private functions in some abstract way. I already have private functions with test cases in them from Octave-forge, so the developers have decided that those functions should be tested. Running those tests has already helped in finding bugs and avoiding regressions.

If we agree on not having tests in private functions, I do not mind. But I do insist that tests coming with Octave or an Octave-forge package are runnable at build time without having to uncomment them or jumping through hoops - we already have most people not running the tests of Octave-forge packages.

Thomas Weber <tweber>
Wed 12 Jun 2013 03:48:43 AM UTC, comment #2: 

It's not generally possible to call private functions, subfunctions, or nested functions directly, so how do you propose to test them individually?

For private functions, you could temporarily place a wrapper function in the directory that contains the private subdirectory, but that's messy (for one thing, it won't work when running the _run_test_suite_ function if the user running the tests can't write in the directory where the functions are stored).  Oh, but any private function that can be used at all already has a wrapper function of some kind in the parent directory.  Otherwise it could not be called at all.  So test those functions thoroughly and that should be sufficient.

For subfunctions, there's just no general way to properly call them directly.  So I don't see how you could test them individually.  Again, I think the solution is to test the parent functions thoroughly, and let it go at that.

Likewise for nested functions.  There is definitely no general way to properly call them directly outside their nested context.

There are still many user-callable functions that do not have any tests, or that have insufficient tests.  So rather than worrying about whether we can test private functions, subfunctions, or nested functions individually, perhaps it would be a better use of our time to write more tests for the functions that users do call directly.

John W. Eaton <jwe>
Group administrator
Tue 11 Jun 2013 08:50:21 PM UTC, comment #1: 

I disagree with the rationale provided here.

Why do we advise users to run "make check"? Because it ensures that compilation was successful and Octave will run as expected.
So, if you include tests in a file, you want those tests to be run after the build, such that problems are found NOW and not at some arbitrary point in the future (if at all).

As such, every test should be run at build time - it does not matter where it is (if the test is known to fail, that's what xtest is for).


Thomas Weber <tweber>
Fri 19 Apr 2013 11:01:56 AM UTC, original submission:  

See:
- bug #38755,
- http://bugs.debia ... rt.cgi?bug=672756
- file ./scripts/miscellaneous/private/__xzip__.m,
- https://mailman.c ... April/033225.html, and

Short summary: there's no way to run tests included in functions in ./private subdirs.

For Octave that's not a problem per se, but for Debian it is.
But it would be good to be able to check proper operation of private functions as well.

Possible solutions (in arbitrary order):
1- While running test script (e.g., scripts/testfun/runtests.m), temporarily extend the PATH to the private subdir at hand and run all tests found there.
2- Move (rip out) tests from private functions to (?the most fitting?) functions in the parent folder.
3- Design tests in functions in the parent folder such that private functions are (implicitly) tested as well.
4- Comment out tests in private functions once correct operation has been verified.

Any others?

Note that 1- (my preferred solution) may not directly help Debian, but IMO that's not a first priority for Octave anyway (OTOH no reason to ignore them).

Philip Nienhuis <philipnienhuis>
Group Member

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by tweber (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    History

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-09-17 rik5 CategoryConfiguration and Build System Test Suite
        Item GroupNone Feature Request
        StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.16-11ef.
    Corresponding source code