I've found that bottom-up development favors testable code. That is, rather than thinking of the problem to be solved, thinking in terms of the tools (functions) one would use to solve the problem. These tools can be written to be testable, and then it all builds up in this tower of easily-testable and easy-to-use things until you have to actually solve the problem at hand, at which point, ideally, it's just the boring work of writing down the problem in terms of these tools. (Digression: languages that let you do this earn the well-earned reputation that source code can be like pseudocode).
It also makes the functions smaller and easier to read, which is a nice bonus, especially during test failures -- lots of functions mean your tests can be granular and say exactly where the problem is (more or less), whereas being easy to read means less time searching for the mistake. -- Devin On Wed, Jan 4, 2012 at 10:48 PM, brian arb <brianjames...@gmail.com> wrote: > > What are some of the strategies for designing code to be unit tested? > > > > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
