[TIP] 5 lines of code equals 30+ lines of single test

[Ben Finney]

John Wong <gokoproject at gmail.com> writes:

> 2. When thinking pure mocking vs real physical fixture data (make real
> folders and files), which one do people prefer? Is that a style thing or
> actually a real concern?

It's a matter of what kind of test you're doing.

If it's testing that a function does some specific yes-or-no thing given
particular input and state, then that's a unit test. You should go to
reasonable steps to isolate that function from anything that isn't
determined by your test case.

If it's testing that a complex part of your pgram, or the whole thing
from end to end, does a whole series of things, then that's no longer a
unit test and the ‘unittest’ module isn't as helpful. Feature testing
libraries like Behave <URL:http://pypi.python.org/pypi/behave> are
better suited to that.

By designing your functions so that they're less dependent on expensive
setup to run unit tests, you'll be designing your program more robustly
and flexibly. In other words, working with that constraint will tend to
lead to a program of loosely-coupled, well-specified parts – good design.

> 3. Whether with or without mock, should I always write some tests for
> checking exception? For example, reading a file may raise OSError if
> the file does not exist. I don't need to raise exception in my code
> because the library (os module in this case) will raise it in its
> implementation.

If your code isn't meant to do anything with the exception, then there's
not much benefit in writing tests for it.

> 4. So are you guys saying that anything that require some states
> (database, writing to file, etc) is okay to mock and check they are
> called with the right parameters?

I'm saying that, while there are times you will need to do that, the
better course is to strive to make less of your code dependent on such
expensive and complex state.

A big part of the job of programming is writing well-specified
abstraction layers so that complexities like that become manageable
within the rest of your program – the rest being what does the
interesting job you wrote the program for in the first place.

-- 
 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\      Brain, but how will we get the Spice Girls into the paella?” |
_o__)                                           —_Pinky and The Brain_ |
Ben Finney