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

[John Wong]

Thank you guys. Sorry for the late response. I've been busy with other
things, but I've been reading comments and books on the related subject.

1. For this particular project, I use a lot of os and shutil. Most of them
require "states". For example, os.path.listdir requires a state of the file
system, so to me it might be a good idea to return a fake list immediately?
shutil.delete shutil.move will also require verification of the state (the
inputs). I think these are also valid to mock?

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?

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. But
for completeness,
       a) if I mock it, I can use side_effect to create an exception
       b) without mocking something like open function, I will have to
supply a non-existing path.
To me, it seems pointless to catch exception in this particular case... if
I am not doing anything useful like rollback (delete temp file, for
example)? Do you guys agree?

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? or do I just mock them out without checking their call
args list?


Thanks.

On Fri, Jul 20, 2012 at 9:35 PM, Ben Finney <ben+python at benfinney.id.au>wrote:

> 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
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20120723/5d7d5082/attachment.htm>