Access to non-public class members

Question

tom 2024-2-9

1
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2080321-access-to-non-public-class-members

编辑： tom 2024-2-13

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

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Matt J 2024-2-11

1
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2080321-access-to-non-public-class-members#answer_1406616

编辑：Matt J 2024-2-11

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.

2 个评论
显示无隐藏无

tom 2024-2-12

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 2024-2-12

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

请先登录，再进行评论。

Answer 2

Tijana Röhrer 2024-2-12

2
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2080321-access-to-non-public-class-members#answer_1407001

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

1 个评论
显示 -1更早的评论隐藏 -1更早的评论

tom 2024-2-13

编辑：tom 2024-2-13

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 2024-2-9

1
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2080321-access-to-non-public-class-members#answer_1405906

编辑：Walter Roberson 2024-2-11

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

5 个评论
显示 3更早的评论隐藏 3更早的评论

tom 2024-2-11

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 2024-2-12

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 2024-2-12

编辑：tom 2024-2-12

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.

请先登录，再进行评论。