Testing private functions in classes

I'm wondering what the best way is to write unit tests for private functions and properties in classes. Say for example, I have a class that represents a ball launched as a projectile:

class ball
  %
  properties (Access = private)
     initialSpeed = 25;  %m/s
     acceleration = -10;  %m/s^2
  end
  %
  methods 
    function distTravelled = getDistanceTravelled(obj, timeElapsed)
        % Estimate total distance traveled by the ball 
        % (I know this is a bad approximation)
        currSpeed = obj.getCurrSpeed(timeElapsed);
        distTravelled = 0.5 * (obj.initialSpeed + currSpeed) * timeElapsed;
    end
  end
  %
  methods (Access = private)
      function currSpeed = getCurrSpeed(obj, timeElapsed)
         %Calculate current speed of ball
         currSpeed = obj.initialSpeed + obj.acceleration * timeElapsed;
      end
  end
end

How should I write a test to check that the values for acceleration or that the value returned by the method getCurrSpeed is accurate? Should I just allow access to the testing functions?

Answer 1

[per isakson]

First goggle "test private method" and read about why you should not do it (and a few ways to do it).

One way (for handle classes only) is to include the test in the class itself.

>> mc = MyClass
mc = 
  MyClass with no properties.
>> mc.test_private
Private mysort is running
>>

where

classdef    MyClass < matlab.unittest.TestCase
    %
    methods ( Test )
        function test_private( this )
            this.mysort
        end
    end
    methods ( Access = private )
        function  mysort( this )
            fprintf( 'Private mysort is running\n' )
        end
    end   
end

A better workaround based on localfunctions (added 19 hours later)

>> mc = MyClass;
>> fh = mc.get_local_function_handle;
>> fh = fh{1}
fh = 
    @the_tricky_algorithm_
>> fh( mc )
ans =
   144
>>

where in one mfile

classdef    MyClass 
    properties
        val = 12;
    end
    methods 
        function    fh = get_local_function_handle( ~ )
            fh = localfunctions();
        end
    end
    methods ( Access = private )
        function  my_private_method( this )
            fprintf( 'Private mysort is running\n' )
            the_tricky_algorithm_( this )
        end
    end   
end
function    out = the_tricky_algorithm_( this )
    out = this.val .* this.val;
end

[JWTay]

Thanks for the reply and some ideas on how to implement this. localfunctions might be how I end up implementing the testing.

Seems like there are a lot of discussion about whether to test private methods or not. For example:

• https://stackoverflow.com/questions/5601730/should-private-protected-methods-be-under-unit-test
• https://stackoverflow.com/questions/105007/should-i-test-private-methods-or-only-public-ones

[Walter Roberson]

When I worked in industry, we tested everything.

Later I worked with some people developing medical devices; I'm pretty sure their applications would have been rejected if they didn't test everything.

[JWTay]

Good to know! I am trying to develop a "best practices" in regards to my coding so I appreciate the info.

Answer 2

[Wil Koenen]

If you're using matlab.unittest.TestCase for your test, but you don't want matlab.unittest.TestCase to be a superclass of the class under test, you can grant access to private functions by providing a list of classes instead of the private keyword. Example:

classdef classUnderTest
    ...
    methods ( Access = { ?classUnderTest, ?matlab.unittest.TestCase } )
        ...
    end   
end

[Tom Hawkins]

Thanks, that's a great tip!

[Martin Lechner]

This solution works perfect. Thanks.

I enabled explictly my test class but this included my unit test class in the compiler output. Your solution to enable access for all matlab.unittest.TestCase doesn't include the test classes in the compiler output.

[Paul Wintz]

Great answer. Note, however, that you don't need to include ?classUnderTest in the list (see here).

Answer 3

[Sean de Wolski]

I would test it through the front door with a known set of inputs and expected outputs. This is the beautiful thing about classes in that you can mask the implementation from the outside world and change it later if necessary.

e.g.:

In Unit Test

b = ball
distTravelled = getDistanceTravelled(b, 20);
testCase.verifyEqual(distTravelled, whatever_is_right_for20);
distTravelled = getDistanceTravelled(b, 200);
testCase.verifyEqual(distTravelled, whatever_is_right_for200);
testCase.verifyError(@()getDistanceTravelled(b, -2), 'ball:NoNegativeTime');

You can use the Code Coverage Plugin for a test runner to make sure that you're exciting all of the lines of the implementation and that should be fine.

[JWTay]

That is my practice in general.

I guess that the reason I wanted to test some of the private functions is to make sure that the calculations are correct, and this is not directly reflected in the output (i.e. the results of the private methods are used to influence some decision-making in the code). I could come up with model input/expected output data but when it breaks, it might not be easy to trace which function was giving the wrong answers.

Answer 4

[Sanjana Ramakrishnan]

Refer the below link for an example of writing MATLAB unit tests relevant to your case:

https://www.mathworks.com/help/matlab/matlab_prog/write-simple-test-case-using-classes.html

Please note that testing private functions is just the same as testing any other function in a class.

You can design your own testing strategies as per your requirement.

[per isakson]

"testing private functions is just the same as testing any other function in a class" Is that really so?

Answer 5

[Tom Hawkins]

Would you be happy to define your properties/methods as Protected, rather than Private? If so you could then create a subclass of your class as part of your test suite, for example:

classdef BallWithAccessToProtected < ball
    methods
        function obj = BallWithAccessToProtected(varargin)
            obj@ball(varargin{:})
        end
        function SetProtectedProperty(obj, prop, value)
            obj.(prop) = value;
        end
        function v = GetProtectedProperty(obj, prop)
            v = obj.(prop);
        end
    end
end

This subclass exposes the protected properties via its SetProtectedProperty and GetProtectedProperty methods, for example:

>> b = BallWithAccessToProtected(someArgs);

>> b.GetProtectedProperty('initialSpeed')

ans =

25

You can figure out how to extend that to accessing methods if you need to.

Protected means that users of your class's 'official' API can't access those properties and methods, but someone who's willing to subclass it can (as we've done above) - but remember that some languages like Python don't even have a mechanism for restricting access to internal properties and methods of a class, only a naming convention to show which ones you shouldn't really use.

[Wil Koenen]

In your example, you could leave out the constructor, because MATLAB supplies a default constructor that does the same (reference).

When a subclass does not define a constructor, the default constructor passes its inputs to the direct superclass constructor. This behavior is useful when there is no need for a subclass to define a constructor, but the superclass constructor does require input arguments.