Roy Smith <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Ben Finney <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
