By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,751 Members | 1,158 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,751 IT Pros & Developers. It's quick & easy.

Re: Testing private methods

P: n/a
Hi.

Thomas Mlynarczyk wrote:
The last option seems the best so far, but I'm still not quite happy as
I'd have to do without "private" and mis-declare private methods as
protected.
Why do you want them to be private in the first place? I have yet to see
code where this really makes sense...

And if it does, then the external public API is what counts, if the code
as a whole still delivers what it promises, and that can be tested, it
should be fine.

Regards,
Karsten
Aug 20 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Karsten Dambekalns wrote:
Why do you want them to be private in the first place? I have yet to see
code where this really makes sense...

And if it does, then the external public API is what counts, if the code
as a whole still delivers what it promises, and that can be tested, it
should be fine.

Regards,
Karsten
Going farther, if the methods are private probably is because they are
accessed by scope methods which, probably again, are public methods.
An alternative approach IMO is to catch this errors from private
methods on the calls (with try..catch or returning vars), and then
apply an testing method only for the callers, the public methods.
Thiago
Aug 20 '08 #2

P: n/a
Karsten Dambekalns schrieb:
And if it does, then the external public API is what counts, if the code
as a whole still delivers what it promises, and that can be tested, it
should be fine.
If such a test fails, it would be difficult to track down the cause of
the problem. That's why it is absolutely necessary to test the (usually
lower level) private methods to make sure they do their part right.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 20 '08 #3

P: n/a
Thomas Mlynarczyk wrote:
Karsten Dambekalns schrieb:
>And if it does, then the external public API is what counts, if the
code as a whole still delivers what it promises, and that can be
tested, it should be fine.

If such a test fails, it would be difficult to track down the cause of
the problem. That's why it is absolutely necessary to test the (usually
lower level) private methods to make sure they do their part right.

Greetings,
Thomas
Then write public methods of the class to test the private methods.
When you're through testing, get rid of the test methods.

However, I never test private methods like that. What's more important
is that they work properly *within the class*. For instance - the
private method may work perfectly correctly - until one of the public
methods passes it incorrect (or unexpected) data...

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 20 '08 #4

P: n/a
Karsten Dambekalns schrieb:
Why do you want them to be private in the first place? I have yet to see
code where this really makes sense...
Well, of course the code would still work if I made them public. The
point is that such access qualifiers are meant to indicate whether a
method is meant to be called by the "user" of the class or if it's for
internal use only. In the latter case, a direct call from "outside"
could mess up things - or the method might simply be refactored away in
a future version. Thus, "private" as an indicator makes perfect sense.
The fact that PHP actively prevents access violations is just a means of
indicating possible errors.

If I assume that anyone messing with my code knows what (s)he's doing,
then I would not need PHP to actively enforce my access declarations and
"private" would simply be a hint for programmers. However, it would be
semantically wrong to label a method as public when it is meant to be
private.

For testing/debugging it would be nice to have the possibility to
temporarily/dynamically enable access to private methods - at least for
specific callers. It should be possible to write an extension to PHP
which allows that.

Another problem are constants which, once defined, cannot be un- or
redefined - something that would be useful for testing as well.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 20 '08 #5

P: n/a
Jerry Stuckle schrieb:
Then write public methods of the class to test the private methods. When
you're through testing, get rid of the test methods.
That would be an option. Still, I'd have to modify my code for testing.
However, I never test private methods like that. What's more important
is that they work properly *within the class*.
Yes. And how do I test that?
For instance - the
private method may work perfectly correctly - until one of the public
methods passes it incorrect (or unexpected) data...
Yes, and if I could test the private method, I would know that it does
what it's supposed to do when I feed it correct data - thus the culprit
must be my public method. If I only test the public method, I would have
to find out where exactly the problem is - especially if my class does
very complicated things internally and exposes only a very simply interface.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 20 '08 #6

P: n/a
Thomas Mlynarczyk wrote:
Jerry Stuckle schrieb:
>Then write public methods of the class to test the private methods.
When you're through testing, get rid of the test methods.

That would be an option. Still, I'd have to modify my code for testing.
>However, I never test private methods like that. What's more
important is that they work properly *within the class*.

Yes. And how do I test that?
>For instance - the private method may work perfectly correctly - until
one of the public methods passes it incorrect (or unexpected) data...

Yes, and if I could test the private method, I would know that it does
what it's supposed to do when I feed it correct data - thus the culprit
must be my public method. If I only test the public method, I would have
to find out where exactly the problem is - especially if my class does
very complicated things internally and exposes only a very simply
interface.

Greetings,
Thomas
You call the public methods with both valid and invalid parameters. If
it does what it's supposed to, great. If not, you find the problem and
fix it.

It's a standard OO debugging technique - I've used it for over 20 years
on both small and large projects.

What's important here is not the behavior of the private method - but
the behavior of the object.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 21 '08 #7

P: n/a
Thomas Mlynarczyk wrote:
Karsten Dambekalns schrieb:
>Why do you want them to be private in the first place? I have yet to
see code where this really makes sense...

Well, of course the code would still work if I made them public. The
point is that such access qualifiers are meant to indicate whether a
method is meant to be called by the "user" of the class or if it's for
internal use only. In the latter case, a direct call from "outside"
could mess up things - or the method might simply be refactored away in
a future version. Thus, "private" as an indicator makes perfect sense.
The fact that PHP actively prevents access violations is just a means of
indicating possible errors.

If I assume that anyone messing with my code knows what (s)he's doing,
then I would not need PHP to actively enforce my access declarations and
"private" would simply be a hint for programmers. However, it would be
semantically wrong to label a method as public when it is meant to be
private.

For testing/debugging it would be nice to have the possibility to
temporarily/dynamically enable access to private methods - at least for
specific callers. It should be possible to write an extension to PHP
which allows that.

Another problem are constants which, once defined, cannot be un- or
redefined - something that would be useful for testing as well.

Greetings,
Thomas
If someone is "messing with your code" - it's not your problem. It's
theirs.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 21 '08 #8

P: n/a
Jerry Stuckle schrieb:
If someone is "messing with your code" - it's not your problem. It's
theirs.
I absolutely agree, but what is the rationale for having "private" and
"protected" then - as an actively performed access control, rather than
just a hint?

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 21 '08 #9

P: n/a
Thomas Mlynarczyk wrote:
Jerry Stuckle schrieb:
>If someone is "messing with your code" - it's not your problem. It's
theirs.

I absolutely agree, but what is the rationale for having "private" and
"protected" then - as an actively performed access control, rather than
just a hint?

Greetings,
Thomas
It is access control, but it is not security. It prevents people from
calling methods which are not meant to operate on their own.

Public methods are the interface. Private methods, class variables and
the code in your methods are the implementation.

You can change the implementation all you want, and you can extend the
interface. But you can't change the existing interface or it's behavior
once you've put the class into production.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 21 '08 #10

P: n/a
Jerry Stuckle schrieb:
Does this help?
Yes, I think it made the matter a bit clearer for me. Thank you.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 21 '08 #11

P: n/a
Jerry Stuckle schrieb:
It is access control, but it is not security. It prevents people from
calling methods which are not meant to operate on their own.
But how often does it actually happen that someone tries to call a
private method by mistake from "outside"? Wouldn't it be sufficient to
just have the access declaration in the code, but without PHP enforcing
anything? In that case, someone reading the code would see that a method
is meant to be private, but *could* still call it if special
circumstances (testing/debugging) demanded it.
Public methods are the interface. Private methods, class variables and
the code in your methods are the implementation.
You can change the implementation all you want, and you can extend the
interface. But you can't change the existing interface or it's behavior
once you've put the class into production.
Yes, that part was clear to me. I was just wondering if the fact that
PHP actually prevents you from accessing a private method from outside a
class is a good thing or not.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 21 '08 #12

P: n/a
Thomas Mlynarczyk wrote:
Jerry Stuckle schrieb:
>It is access control, but it is not security. It prevents people from
calling methods which are not meant to operate on their own.

But how often does it actually happen that someone tries to call a
private method by mistake from "outside"? Wouldn't it be sufficient to
just have the access declaration in the code, but without PHP enforcing
anything? In that case, someone reading the code would see that a method
is meant to be private, but *could* still call it if special
circumstances (testing/debugging) demanded it.
No, that would be a violation of OO principals. Private means exactly
that. It is private to the class and not meant to be called from
outside. This is because normally private methods make some assumptions
about the parameters and class variables which may not be valid when
called from outside.

If you wanted it as a recommendation, you could always just put a
comment in front of the method:

// WARNING: INTERNAL USE ONLY. DO NOT CALL!
>Public methods are the interface. Private methods, class variables
and the code in your methods are the implementation.
>You can change the implementation all you want, and you can extend the
interface. But you can't change the existing interface or it's
behavior once you've put the class into production.

Yes, that part was clear to me. I was just wondering if the fact that
PHP actually prevents you from accessing a private method from outside a
class is a good thing or not.

Greetings,
Thomas
All true OO languages do this - SmallTalk, C++, Java, etc. It's all a
part of OO design. By making a method private, you can ensure it won't
be called.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 21 '08 #13

P: n/a
Jerry Stuckle schrieb:

[if PHP would not prevent calling private methods from outside...]
No, that would be a violation of OO principals. Private means exactly
that. It is private to the class and not meant to be called from
outside.
I did not deny that they are not *meant* to be called from outside. But
there may be cases where breaking the principles is legitimate - like
debugging. And for *such* cases, it would make things much easier if
there were no enforced access restrictions.
This is because normally private methods make some assumptions
about the parameters and class variables which may not be valid when
called from outside.
The one who wrote the code or other "authorized staff" (who are assumed
to know exactly what they're doing) might need a direct access to
private methods (e.g. for logging calls to them) and for that a
decorator would, IMHO, be the perfect solution. But of course, the
decorator would need to be able to access the private methods.
Currently, the only way to achieve this is to use "protected" instead of
"private".
If you wanted it as a recommendation, you could always just put a
comment in front of the method:

// WARNING: INTERNAL USE ONLY. DO NOT CALL!
The "private" keyword does this job perfectly.
All true OO languages do this - SmallTalk, C++, Java, etc. It's all a
part of OO design. By making a method private, you can ensure it won't
be called.
....under "normal circumstances". I'm talking of special circumstances
here. Python, for example, has private members. But if you need to, you
*can* still access them from outside. No law can foresee each and every
future case. Thus it is imperative to have some kind of "meta-law" which
makes sure that a law will do no harm in an unforeseen situation and can
be ignored if such a situation arises.

Greetings,
Thomas

--
Ce n'est pas parce qu'ils sont nombreux avoir tort qu'ils ont raison!
(Coluche)
Aug 22 '08 #14

P: n/a
Thomas Mlynarczyk wrote:
Jerry Stuckle schrieb:

[if PHP would not prevent calling private methods from outside...]
>No, that would be a violation of OO principals. Private means exactly
that. It is private to the class and not meant to be called from
outside.

I did not deny that they are not *meant* to be called from outside. But
there may be cases where breaking the principles is legitimate - like
debugging. And for *such* cases, it would make things much easier if
there were no enforced access restrictions.
>This is because normally private methods make some assumptions about
the parameters and class variables which may not be valid when called
from outside.

The one who wrote the code or other "authorized staff" (who are assumed
to know exactly what they're doing) might need a direct access to
private methods (e.g. for logging calls to them) and for that a
decorator would, IMHO, be the perfect solution. But of course, the
decorator would need to be able to access the private methods.
Currently, the only way to achieve this is to use "protected" instead of
"private".
>If you wanted it as a recommendation, you could always just put a
comment in front of the method:

// WARNING: INTERNAL USE ONLY. DO NOT CALL!

The "private" keyword does this job perfectly.
>All true OO languages do this - SmallTalk, C++, Java, etc. It's all a
part of OO design. By making a method private, you can ensure it
won't be called.

...under "normal circumstances". I'm talking of special circumstances
here. Python, for example, has private members. But if you need to, you
*can* still access them from outside. No law can foresee each and every
future case. Thus it is imperative to have some kind of "meta-law" which
makes sure that a law will do no harm in an unforeseen situation and can
be ignored if such a situation arises.

Greetings,
Thomas
Thomas, you can't have it both ways. A method can be private or not
private. If it's private, there is no way to call it from outside the
class. That's what OO is all about.

Part of the problem here is that you're still thinking in a
function-oriented manner, where the functions themselves are important.
In an object-oriented system, though, the functions themselves are NOT
important. Only the interface and behavior is. And testing a private
method outside of its intended environment can produce incorrect results.

What you want to do is test your object's behavior, not individual
functions.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Aug 22 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.