Closed cbm755 closed 5 years ago
Why not test @myclass
?
A few years ago, I posted some patches to do some of this:
https://savannah.gnu.org/patch/?9220
Feel free to cherry pick if these still apply.
Is there a reason why @
-sign would be required or preferable for this? Or would test myclass
be sufficient?
Good question... doctest seems to usually do the same thing for doctest @myclass
and doctest myclass
..., although I checked the code and their are some subtleties, e.g., doctest @logical
(Symbolic has @logical/isAlways
) methods and doctest logical
(the builtin
)
>> pkg load symbolic
>> pkg load doctest
>> doctest logical
Doctest v0.6.1: this is Free Software without warranty, see source.
logical ................................................ NO TESTS
Summary:
PASS 0/0
1/1 targets passed, 1 without tests.
>> doctest @logical
Doctest v0.6.1: this is Free Software without warranty, see source.
logical ................................................ NO TESTS
@logical/isAlways ...................................... PASS 2/2
Summary:
PASS 2/2
2/2 targets passed, 1 without tests.
I think the same distinction could apply for #!
BISTs.
Is there a reason why @-sign would be required or preferable for this? Or would test myclass be sufficient?
You might need it to disambiguate between running tests for the whole class, and running tests for just the constructor. If you have a class named foo
, then the function foo
is the constructor for it, and matches the test <function_name>
calling form, too.
You might need it to disambiguate between running tests for the whole class, and running tests for just the constructor.
Yeah, there was a similar discussion over at https://github.com/catch22/octave-doctest/issues/196, you might be interested in weighing in over there too.
I posted a summary of my thinking based on that thread here
I think the same logic would apply for regular tests. Which suggests there could be some "parse this object for tests" common code.
I think I mostly agree, and think that the whole test selection logic (and command syntax) for doctest and this BIST stuff can probably be the same.
My current thinking is that there are two layers of test discovery:
test
or runtests
command-style functions and parses them into the specifier data structures used by layer 2.But then if you wanted to test just a single method or constructor from a class, you couldn't use the specifier -> files -> tests mapping, because you'd only want some selected tests from within a classdef file. So that's probably not the right design after all.
Oh – can BISTs actually be associated with a particular method within a classdef file? All the ones I recall seeing just have all the tests in a block down at the bottom of the file.
I think almost everything about Octave's classdef support is in flux. What is certainly true is that separate .m files specifying class methods can have their own tests associated with them. That is @klasdef/mymethod.m
as opposed to methods defined "inline" in @klasdef/klasdef.m
.
Ah, that makes sense. And that way, the 1 specifier -> 1 or more files -> all tests from those files mapping sequence works.
This is in. It's in runtests2_refactor
. You can call it with either of these forms:
runtests2_refactor @myclass
runtests2_refactor -class myclass
You can also do runtests2_refactor myclass
, and it might work, depending on what else "myclass
" could resolve to.
Support for namespaces and dot-referencing of constructors or class methods is not supported yet.
Why not test @myclass?
As things stand now, test
acts on a single file, and classes may have multiple files in their definition. Unless we merge runtests
and test
, then the support needs to go at the runtests
level.
Closing this as fixed since the basic mechanism is working. Adding a #49 for adding namespace support.
Ha! I found a quick-and-dirty way to add namespace support. https://github.com/apjanke/octave-testify/commit/39905642604642dc79947e38d56be7bfbf3e51c7
I'd like to see
runtests
be the main driver. Soruntests @myclass
would run the tests in class@myclass
.Consider looking at Doctest: https://github.com/catch22/octave-doctest/blob/master/inst/doctest.m There we wanted
doctest thing
to DTRT:doctest my_fcn
worksdoctest @klass
worksdoctest octfile.oct
works (and is subtly different thandoctest octfile
.doctest dir
works recursively, possibly staying out ofprivate/
subdirs (I forgot).