In general, write the unit test *before* you write the code. This way your code is "designed" to be unit tested by default. It also provides a better way to verify that your implementation of a desired feature actually works as intended.
For example, when I'm writing a new module I document it first. That is, I write up a bunch of code samples on how to use the module. This gives me a feel for what features I want and how I want the module to work. This is my sketch. I use the Sphinx documentation generator for this, but it could be as simple as a text document. After that I write a bunch of unit tests, which fail because there is no module written yet. Then, I write the module code to make each unit test pass, one by one. If I want a new feature I document it, write the unit test, then implement it until the unit test passes. If a feature is difficult to unit test, you probably need to re-think how you're implementing it, or re-think the interface itself. That said, this isn't always the case. With code that has to interact with many external programs, unit testing certain features can be difficult, if not impossible. Just try to get the best coverage you can. Everyone has a little different process, but that's how I do it. -Modulok- On 1/4/12, 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
