Access to non-public class members

Hello,

I'm currently writing unittests for a code-base which I'm not supposed to change (and honestly don't want to change). To say it nicely, its not written very testable. However I managed to test at least some parts of it. To increase the test coverage and to test things more defensively,

I would like to access non-public class members, such as private methods and properties.

As expected the following statement fails:

myInstance.privateMethod 
% yields -> Cannot access method 'privateMethod' in class 'CustomersAwesomeClass'.

What I would like to see working is something like this:

% imaginary code, (similar to the invoke function for COM interfaces)
invoke(myInstance, "privateMethod", arg1 ...)

After spending a day trying various hacks, I'm about to give it up. Isn't it possible to achieve it somehow?

In other programming languages there are direct and indirect mechanisms like Reflection, Metaprogramming, Extensions methods, Friends, Function pointers, Runtime patching and others to achieve it. In MATLAB it seems none of these solution are doable and I don't understand why this is the case.

In my oppinion, access modifiers are supposed to prevent a wrong usage of an interface, but it should not prevent you from invoking code, because there might always be a usecase for that. This is also why there are many languages out there without access modifiers at all...

Anyway, if someone knows a workaround, then please share it with me! Other than that it would also be a solution to get a definitive answer that this is not doable, so that I stop wasting time on this. And if so, maybe Mathworks considers to introduce a backdoor here in the future then...

Any help is appreciated. Thanks

Answer 1

[Matt J]

You could move the classdef to an @-folder, either manually or programmatically and either temporarily or permanently. Then, add invoke() as a method of the class in a separate mfile, so the folder looks like:

@CustomersAwesomeClass/CustomersAwesomeClass.m

@CustomersAwesomeClass/invoke.m

Now that invoke() has been made a method of the class, it will have access to private methods and properties. However, because this involves no editing of the classdef file CustomersAwesomeClass.m you can tell the customer that your test was non-invasive.

[tom]

Hello Matt,

this is actually a good idea. I think I could use this approach. It is not an ideal solution, but with delegating invoke method/s during the test setup and removing them during the teardown I should be able to write meaningful tests without changing the clients code-base.

(And of course I'm aware that I'm violating a couple of best practices, but for testing this difficult code-base I break some rules anyway... As long as the client is happy, I am happy ;) )

Thank you

[Matt J]

I'm glad, but if it ends up working for you, please Accept-click the answer.

Answer 2

[Tijana Röhrer]

Hi Tom,

one possibility to test private methods is to allow access to the testing framework. In the definition of the method, instead of setting it's access permissions to "private" directly, you would set them as

methods (Access = ?matlab.unittest.TestCase)

This sets the access to private, but additionally allows access to any subclass of matlab.unittest.TestCase, and therefore any test class. If you use other testing frameworks, you would have to use the appropriate superclass such as matlab.uitest.TestCase etc.

This would require a minor modification to your code, but it might be worthwhile.

Best,

Tijana

[tom]

Hello Tijana,

thank you, this is also great solution. I think it is probally even better. I must say it looks weird, but its indeed an acceptable minimal change.

Wouldn't it make sense that this is the default behavior for private? In C#, I have seen many developers just making functions public for better testing to prevent the usage of reflection. Especially if you develop test-driven. I know the argumentation is often that you don't need to directly test private members because you only assume modification over a public interface, but sometimes it helps you in writing better tests and it makes assertions of internal states easier. Anyway, Thanks :)

Answer 3

[Walter Roberson]

In my oppinion, access modifiers are supposed to prevent a wrong usage of an interface, but it should not prevent you from invoking code, because there might always be a usecase for that.

External access to a non-public property is a "wrong usage of an interface" and MATLAB blocks that access.

It is an access contract: the class is written under the assumption that only the contracted operations can happen, and MATLAB enforces that indeed only the contracted operations can happen.

If there are backdoors possibilities then classes need to be written to protect against the backdoors, by using techniques such as checking the call stack to verify that the call is legitimate.

Consider a class that is acting like a bank account, with defined deposit and withdrawl methods. You do not want there to be a backdoor that permits you to withdraw without a trace.

I suspect that what you are looking for is something like the facility for mocking; https://www.mathworks.com/help/matlab/mocking-framework.html

[tom]

Hi Walter,

thank you for your response. I don't know if this helps me. Maybe I'll dive more into the mocking framework and see if I see something which can help me. But I assume the code needs to be mockable in first place, which is not the case here.

Other than that, let me argue against your view a bit. The problem with your argumentation is, that in practice a developer can hardly predict the use-case of an interface. I would even argue that making things public or private is often more a random decision than based on rational argumentation. Sure if its about internal state manipulation or similar, things should stay private for security reasons, but often its rather a matter of believe what a potential consumer would call.

Even if it remains a rare use-case, but if I want to access private modifiers in C#, C++ and similar I can invoke private members from outside by using various techniques. So I can workaround it. Matlab just seem to strict here. Or am I missing something?

Again I'm not the author of these components, and I don't want to modify them. It is obvious if the developer would have thought about testability more, I could mock dependencies out or fully test the system. But in this particular case I simply don't have that solution and I would like to workaround it, if doable...

[Walter Roberson]

MATLAB has a unit testing framework https://www.mathworks.com/help/matlab/matlab_prog/ways-to-write-unit-tests.html and a mocking framework https://www.mathworks.com/help/matlab/mocking-framework.html

Everything beyond that is considered misuse of internal members and is blocked.

Sure if its about internal state manipulation or similar, things should stay private for security reasons, but often its rather a matter of believe what a potential consumer would call.

MATLAB is not able to somehow evaluate the importance of a section of code to know whether it represents a bank account (high security required) or a hodge-podge of code in which the declarations are more or less random (backdoors desired.) It has to assume that if methods or members have been declared private that they really have to remain private.

[tom]

Having no backdoor is a very restrictive opinion. And languages vary strongly here, but Matlab is extremistic in this case. Restrictions are not neccessarily making things more secure or better. And having a more liberal opinion about it, can still yield in highly secure software. There is no correlation to this. In my opinion, its all about trust. If you trust too much in the abitity of people in creating perfect interfaces, you make the life just harder for anyone. Again I had a couple of rare use-cases, where doing things differently as intended, solved problems. Not just for testing. You can't always throw the ball back, and ask others to extend their api for various problems, you need to give people ways in solving their problems on their own. I completly agree, that invoking non-public methods is borderline, but having absolutly no ability to do so is even worse.

[Walter Roberson]

And having a more liberal opinion about it, can still yield in highly secure software.

No, you cannot.

If you allow backdoors then you have to write the methods to protect against the possibility that this invocation used a backdoor.

[tom]

Again access modifiers are not a security feature. I assume, that you find more "highly secure software" written in C++ than in Matlab. You even build C++ apps out of Matlab/Simulink most of the time. So all that so-secure code, is converted in C++ anyways. And if you can do it in C++, you cannot claim that this follows any purpose of security. C does not even know the concept of access modifiers, and so many critical systems still run with C nowadays.