_run_test_suite_ is an internal function, as indicated by the leading and trailing underscores, so it does not do much in the way of input validation.  It expects to be called in the correct manner, which in this case is with absolute paths rather than relative ones.

Additional workarounds,

make_absolute_filename (".")
canonicalize_file_name (".")

Would be easy to write your own wrapper function that takes in cell arrays and then does

y = cellfun (@make_absolute_filename, x, "UniformOutput", false);

before passing to _run_test_suite_

That is the sort of philosophical difference I was trying to point out.  It isn't that important, to me, that _run_test_suite_ doesn't work outside of its design envelope.

If it is useful to have a function that has features such as recursion, error summary, etc. then work should go in to creating that function (possibly by borrowing a lot of the _run_test_suite_ code as the core) rather than twisting _run_test_suite_ to do something it wasn't particularly designed for.

For a simple workaround, run with the full, rather than relative name to the current directory.  This syntax seems to work for me

__run_test_suite__ ({pwd()}, {})

The prototype for the function is

__run_test_suite__ (FCNDIRS, FIXEDTESTDIRS)

As a larger question, why is it important to support running the test suite without running the fixed tests?

If you have just made changes to a specific FILE, then run 'test FILE'.  If you have made several changes in a directory, let's say the image/ functions, then use 'runtests image'.

If you have made changes to something fundamental, say the interpreter, then you need to verify by running the entire suite including the fixed tests as well as the per-function tests.  This requires specifying the FIXEDTESTDIR directory.

Minimal example

octave:2> d = '.'
d = .
octave:3> [dnm, fnm] = fileparts (d)
dnm =
fnm =

Then fnm(1) fails because fnm is empty.