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

[Ben Finney]

Ned Batchelder <ned at nedbatchelder.com> writes:

> On 7/18/2012 2:46 PM, John Wong wrote:
> > Another test will tests that `open` is called with f_path and `r` ?
> > Only patch the function that your test is actually depending on? In
> > the first time, we want to know local is used, and the immediate use
> > of this local` variable is os.path.join. So patching out
> > os.path.join seems reasonable?
> >
> No, in my opinion, you never need to patch os.path.join to test this
> function. You don't care whether os.path.join was called. You only
> care that it opened the right file. So test that.

Another way to look at it:

The ‘os.path.join’ function is internal to Python, and its
implementation is not your responsibility. On the other hand, it is very
inexpensive to use: it's non-destructive, non-intrusive, and fast. So
there is very little cost in having the real function called from your
code. That strongly suggests there is no good reason to avoid calling
the real ‘os.path.join’ when running your unit tests.

The ‘open’ function, on the other hand, is an external interface from
your program to the rest of the world. It creates a dependency from your
program to the state of the filesystem, and to make your tests reliable
would require that you somehow set up a reliable result for ‘open’ every
time. This suggests that ‘open’ may be a good candidate for mocking
during your unit tests, to have it return a fake file object which will
behave exactly as you determine.

The upshot of this perspective is that I frequently mock the ‘open’
function in my unit tests to simply return a fake (usually StringIO)
file object; but I have never seen a good reason to mock the
‘os.path.join’ function.

I try to apply the same principle when deciding whether to mock other
parts of the system. Is this very expensive and/or overly dependent on
external state? If so, it may be a good candidate for mocking; if not,
it probably is not.

-- 
 \        “There are no significant bugs in our released software that |
  `\         any significant number of users want fixed.” —Bill Gates, |
_o__)                                                       1995-10-23 |
Ben Finney