Why does python not have a mechanism for data hiding?

Ben Finney bignose+hates-spam at benfinney.id.au
Fri Jun 6 00:13:03 CEST 2008

Roy Smith <roy at panix.com> writes:

> In article <87prqwltqi.fsf at benfinney.id.au>,
>  Ben Finney <bignose+hates-spam at benfinney.id.au> wrote:
> > Then what you're really testing is the interactions of the "push
> > the button" function with its external interface: you're asserting
> > that the "push the red button" function actually uses the result
> > from "pick a random city" as its target.
> No, that's not what I'm testing at all. I want to test that the
> cities really do get picked randomly.

Then you need to make a design decision, by *specifying* that expected
behaviour in some public API.

Either "pick a random city" is public API with the expected behaviour
that it will return a random city from a publicly-specified list of
cities; or the "push the button" function has some
externally-verifiable target that is specified.

If the behaviour you describe isn't part of the specified API, then it
*doesn't matter* how the city gets picked (i.e. it's an internal
implementation detail); selecting New York every time doesn't go
against any description of the behaviour of the application, so it's
not a bug, but an internal implementation detail that doesn't deserve
to be unit tested.

If you want "always chooses the same city" to be a bug, then you are
specifying some externally-expected behaviour of the application code,
and that expectation needs to be specified in such a way that you can
make an automated assertion about it in a unit test.

Once you've decided which public API is specified as providing that
behaviour, that's the point at which the unit test should be asserting
that behaviour.

 \    "Know what I hate most? Rhetorical questions."  -- Henry N. Camp |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

More information about the Python-list mailing list