[Tutor] Your thoughts on designing python code for unit testing?

[Modulok]

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 <brianjamesarb at gmail.com> wrote:
> What are some of the strategies for designing code to be unit tested?
>