Why does python not have a mechanism for data hiding?
Ben Finney
bignose+hates-spam at benfinney.id.au
Thu Jun 5 18:13:03 EDT 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