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

 
 

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

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 19 Apr 2013 11:01:56 AM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NoneAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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.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>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by tweber (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup