Robert Kern <[EMAIL PROTECTED]> writes: > Steven D'Aprano wrote: > > Does anyone have generic advice for the testing and development of > > this sort of function? > > "Design for Testability". In library code, never call the functions > in the random module. Always take as an argument a random.Random > instance. When testing, you can seed your own Random instance and > all of your numbers will be the same for every test run.
Even better, you can pass a stub Random instance (that fakes it) or a mock Random instance (that fakes it, and allows subsequent assertion that the client code used it as expected). This way, you can ensure that your fake Random actually gives a sequence of numbers designed to quickly cover the extremes and corner cases, as well as some normal cases. This applies to any externality (databases, file systems, input devices): in your unit tests, dont pass the real externality. Pass a convincing fake that will behave entirely predictably, but will nevertheless exercise the functionality needed for the unit tests. This is one of the main differences between unit tests and other kinds. With unit tests, you want each test to exercise as narrow a set of the client behaviour as feasible. This means eliminating anything else as a possible source of problems. With other tests -- stress tests, acceptance tests, and so on -- you want to exercise the entire application stack, or some significant chunk of it. -- \ "It is the mark of an educated mind to be able to entertain a | `\ thought without accepting it." -- Aristotle | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
