Thu 10 Aug 2017 06:20:35 AM UTC, comment #13:
Thanks Oliver this idea looks good to me!
I found an issue about multiple package names while reviewing this. I'll attach a patch which also adds docs and a return value. My patch applies on top of Oliver's.
|
Thu 19 Feb 2015 02:14:01 PM UTC, comment #12:
Some additional information on this patch and the patch submitted for bug #41298: Together they enable the following new features:
- “pkg test <package>” will run all tests of a particular package. Even tests from .cc sources.
- “pkg test all” will do the same for all installed packages
- “test <functionname>” will also work for OCT-files from packages which have been compiled from .cc sources
Of course, the pkg.m documentation string is to be updated.
|
Thu 19 Feb 2015 01:13:09 PM UTC, comment #11:
Please review the attached patch file. Another patch is posted in bug #41298.
(file #33130)
|
Thu 19 Feb 2015 09:16:37 AM UTC, comment #10:
Good point, it would be a one liner for few .cc files, but becomes unfeasible if the package has a lot of them. I will prepare two patches then.
|
Thu 19 Feb 2015 12:44:21 AM UTC, comment #9:
I agree with all but the first item. There should be a common solution for all packages built in to the pkg command to fix bug #41298. Or do you have a portable one-liner that can easily be stuffed into every Octave Forge package to make tst files?
|
Wed 18 Feb 2015 09:26:48 PM UTC, comment #8:
I propose the following solution:
- The extraction of tests from .cc files is the package maintainers responsibility. The package's Makefile shall contain a build target for .cc-tst files like the Makefiles in octave core. (this solves #41298)
- The “pkg install” shall copy any src/-tst and src/.tst files into the package's target directory.
- The requested “pkg test” can be implemented via pkg load + _run_test_suite_
- Bonus target: The test.m script shall lookup <functionname>.cc-tst files, for simple testing of a single installed OCT-file.
I can provide a patch, if you agree with the proposal.
|
Wed 22 Jan 2014 06:19:08 AM UTC, comment #7:
Re comment #6, I went ahead and submitted another bug for these two additional suggestions about extracting and installing unit tests from .cc files and fixed .tst scripts. This bug doesn't really depend on that being done first, but it does mean that "pkg test foo" will only test m-files until all tests are available in the package directory.
See bug #41298 for the new bug about extracting and installing tests from "pkg install foo".
|
Mon 13 Jan 2014 02:35:46 PM UTC, comment #6:
Indeed having 'pkg test <package name>' would be useful.
The implementation of this feature should be synchronized with the overhaul of "pkg.m" being carried out by JPi and Carnë.
In addition to calling _run_test_suite_ passing the correct
location of the package installation directory, this would require:
1) extract tests from .cc files and store them in he installed package
2) copy directories with fixed test scripts from the tarball to the install location.
c.
|
Mon 13 Jan 2014 02:16:27 PM UTC, comment #5:
> The major differences between runtests and run_test_suite
> are runtests shows errors in the console, does not create
> a fntests.log file, and it lists all function files that
> are missing unit tests.
Other important differences:
- _run_test_suite_ display a summary (number of tests, number of failed tests, etc.) at the end
- _run_test_suite_ also executes tests which are contained in subdirectories
|
Mon 13 Jan 2014 02:14:53 PM UTC, comment #4:
> The function expects the inputs to be passed as
> cell arrays of strings while you are using just
> a string.
>
> You should enclose directory paths in curly braces.
Ok, the following does the job:
but I agree with Mike that it would be better to be able to do this without having to know where the package is.
|
Mon 13 Jan 2014 02:05:07 PM UTC, comment #3:
Yes, both runtests and run_test_suite work given the right paths, but I agree it would be a nice feature to be able to test a package with the pkg command without having to specify paths. The pkg commands already have code for adding the directories of a package to the load path, a new "pkg test" command could make sure the package is loaded and call runtests on each of the directories of the package.
The major differences between runtests and run_test_suite are runtests shows errors in the console, does not create a fntests.log file, and it lists all function files that are missing unit tests.
|
Mon 13 Jan 2014 01:49:22 PM UTC, comment #2:
The function expects the inputs to be passed as cell arrays of strings while you are using just a string.
You should enclose directory paths in curly braces.
c.
|
Mon 13 Jan 2014 12:46:34 PM UTC, comment #1:
> To test all functions in a package I use the internal
> function _run_test_suite_ passing as first argument
> the package install directory.
>
> Does that work better for you?
>
> c.
I have tried but it fails, perhaps am I missing something...
Here is what I do, with Octave 3.8.0:
and I get:
|
Mon 13 Jan 2014 09:15:49 AM UTC, original submission:
It would be nice to a "test" option for the pkg command, that would allow to run the test suite of a given package:
pkg test PackageName
similarly to _run_test_suite_ for Octave core.
See the discussion here: http://octave.1599824.n4.nabble.com/Removing-packages-from-Octave-Forge-td4660799i20.html#a4660902
|