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:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

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:  

- bug #38755,
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672756
- file ./scripts/miscellaneous/private/__xzip__.m,
- https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-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


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -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)

    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.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-7c56.
    Corresponding source code