One of the most often cited coding "best practices" is to avoid structuring the code as one "large" function (or a few large functions), and instead to break it up into many tiny functions. One rationale for this strategy is that tiny functions are much easier to test and debug.
The question is how to implement this "many tiny functions" strategy in MATLAB.
To be more specific, suppose that I start with some "large" function foo, implemented in a ~100-line file foo.m, and I break it down into about ~20 tiny functions, including a new (and much smaller) entry-point function foo that calls the remaining tiny functions, either directly or indirectly.
The problem is that, if the new foo.m file now looks like this:
function f = foo(a, b, c) ...
% End of function foo
function b = bar(d, e) ...
% End of function bar
function z = zzz(x, y) ...
% End of function zzz
...then the "helper" functions bar, ..., zzz are not accessible from outside foo.m, so there's no easy way to test or debug them *directly*. (One can do so only indirectly through calls to the entry-point function foo, and this can be quite cumbersome and error-prone.)
(Note that it would be entirely consistent with the philosophy described above to have, among the "tiny functions" in foo.m, some --say, test_bar, ..., test_zzz, etc.--, whose sole purpose was to test some other "tiny function". Even in this case, however, one would need a way to call these testing functions from outside of foo.m.)
So file structure shown above may not be very useful for testing and debugging. On the other hand, it would be too much clutter (both of directories and of the global namespace) to put all these tiny functions each in its own *.m file (bar.m, ..., zzz.m, test_bar.m, ..., test_zzz.m).
So my question is: is there a convenient way to structure this code that would *both* preserve the overall decomposition into many tiny functions *and* enable these functions to be tested?
Suggestions would be appreciated.
Thanks in advance!
PS. I am aware of the existence of MATLAB xUnit Test Framework, etc., but my aims here is more general and fundamental, and in any case decidedly different, from those of unit testing, and therefore if possible I'd much prefer to avoid bringing into the picture the whole unit testing apparatus and mind-set. I'm sure that the question of the suitability of a unit-testing framework for what I want to do could provide fodder for lengthy discussions, but this is a somewhat philosophical point that I'd prefer to avoid altogether. I hope that responders will be willing to take it on faith my assertion that MATLAB xUnit Test Framework et al. are not what I'm after at the moment.