2

Given a medium-sized (scientific) codebase, how do you proceed to build a unittest-suite? I need to test local functions as well as hidden methods, but I would prefer not to modify/extend classes so far. Is that possible or do i need to inject testcases somehow? How would I best implement this?

Thanks.

PS: I am aware that commonly unittesting refers to testing entire units, but my objects are quite complex and have some very fancy methods, which are constantly modified by the team.

zuiqo
  • 1,149
  • 1
  • 10
  • 23
  • I do have a framework, and I know about the different alternatives. I am looking specifically for an approach to unit test local functions from outside, such that my test suit is separated from the codebase. – zuiqo Jul 07 '14 at 15:22
  • Regarding classes, are you using the new syntax (one m-file per class) or the old syntax (one m-file per method) or both mixed? – Daniel Jul 07 '14 at 17:35
  • possible duplicate of [How to make internal/helper functions testable?](http://stackoverflow.com/questions/25313017/how-to-make-internal-helper-functions-testable) – Andy Campbell Aug 31 '14 at 23:39

1 Answers1

1

For private functions, you can work around the visibility rules creating a function handle:

%get handle for E:\WORKSPACE\MATLAB\private\object_of_test.m
testfun=getPrivateFunction('E:\WORKSPACE','MATLAB','private','object_of_test.m')
%call function
testfun(pi)

getPrivateFunction.m:

function handle=getPrivateFunction(varargin)
p=fullfile(varargin{:});
[d,f,~]=fileparts(p);
olddir=pwd;
cd(d);
handle=str2func(f);
cd(olddir);
end

For possible inputs of getPrivateFunction please check the documentation for fullfile, everything that results in a valid path is allowed.

Daniel
  • 36,610
  • 3
  • 36
  • 69