Thank you guys. Sorry for the late response. I&#39;ve been busy with other things, but I&#39;ve been reading comments and books on the related subject.<br><br>1. For this particular project, I use a lot of os and shutil. Most of them require &quot;states&quot;. 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? <br>
<br>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?<br><br>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&#39;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, <br>
       a) if I mock it, I can use side_effect to create an exception<br>       b) without mocking something like open function, I will have to supply a non-existing path. <br>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?<br>
<br>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? <br>
<br><br>Thanks.<br><br><div class="gmail_quote">On Fri, Jul 20, 2012 at 9:35 PM, Ben Finney <span dir="ltr">&lt;<a href="mailto:ben+python@benfinney.id.au" target="_blank">ben+python@benfinney.id.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Ned Batchelder &lt;<a href="mailto:ned@nedbatchelder.com">ned@nedbatchelder.com</a>&gt; writes:<br>
<br>
&gt; On 7/18/2012 2:46 PM, John Wong wrote:<br>
</div><div class="im">&gt; &gt; Another test will tests that `open` is called with f_path and `r` ?<br>
&gt; &gt; Only patch the function that your test is actually depending on? In<br>
&gt; &gt; the first time, we want to know local is used, and the immediate use<br>
&gt; &gt; of this local` variable is os.path.join. So patching out<br>
&gt; &gt; os.path.join seems reasonable?<br>
&gt; &gt;<br>
&gt; No, in my opinion, you never need to patch os.path.join to test this<br>
&gt; function. You don&#39;t care whether os.path.join was called. You only<br>
&gt; care that it opened the right file. So test that.<br>
<br>
</div>Another way to look at it:<br>
<br>
The ‘os.path.join’ function is internal to Python, and its<br>
implementation is not your responsibility. On the other hand, it is very<br>
inexpensive to use: it&#39;s non-destructive, non-intrusive, and fast. So<br>
there is very little cost in having the real function called from your<br>
code. That strongly suggests there is no good reason to avoid calling<br>
the real ‘os.path.join’ when running your unit tests.<br>
<br>
The ‘open’ function, on the other hand, is an external interface from<br>
your program to the rest of the world. It creates a dependency from your<br>
program to the state of the filesystem, and to make your tests reliable<br>
would require that you somehow set up a reliable result for ‘open’ every<br>
time. This suggests that ‘open’ may be a good candidate for mocking<br>
during your unit tests, to have it return a fake file object which will<br>
behave exactly as you determine.<br>
<br>
The upshot of this perspective is that I frequently mock the ‘open’<br>
function in my unit tests to simply return a fake (usually StringIO)<br>
file object; but I have never seen a good reason to mock the<br>
‘os.path.join’ function.<br>
<br>
I try to apply the same principle when deciding whether to mock other<br>
parts of the system. Is this very expensive and/or overly dependent on<br>
external state? If so, it may be a good candidate for mocking; if not,<br>
it probably is not.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
 \        “There are no significant bugs in our released software that |<br>
  `\         any significant number of users want fixed.” —Bill Gates, |<br>
_o__)                                                       1995-10-23 |<br>
Ben Finney<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
</div></div></blockquote></div><br>