[TIP] mocking a file in /proc

[Tim Ottinger]

Assuming you are doing a unit test (aka microtest):

One easy way to avoid file system dependencies is to separate out a
function that opens the file you specify.
It becomes a very trivial function, of course.

In the test, you stub that function to return a file-like object of the
fake content you need in order for the test to work.
This works just fine whether reading or writing.

Of course, if you want to fake a higher level, you can split out a function
that opens the file and parses the data -- then mock that function out.

If nothing else is easy/quick/handy, you can always extract and mock your
way out of (nearly) any situation.



On Tue, May 9, 2017 at 8:34 AM Gregory Salvan <apieum at gmail.com> wrote:

> I'm not advocating against functionnal tests in my answer, but if you want
> my opinion about them it's best explained here:
> http://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam
>
> Then I've answered for TDD and BDD and not for real live system, the
> purpose is different. By the way if you have cases where it's relevant to
> test open() in real live system, I'm curious.
> Once you've tested open() is called correctly (by injecting a mock of
> open()) what's the point to test if it works in a real live system
> otherwise testing if open() implementation works correctly?
>
> 2017-05-09 14:31 GMT+02:00 Matt Wheeler <m at funkyhat.org>:
>
>> On Tue, 9 May 2017, 11:50 Gregory Salvan, <apieum at gmail.com> wrote:
>>
>>> It's to generic to have complex examples, but you really can test
>>> everything without writing data in files, and it's not really relevant to
>>> test if data are really written as it's the same as testing if there's no
>>> errors in python "open" implementation. I think we can trust python
>>> developpers for that ;)
>>>
>>
>> No, it's not just testing that open() works correctly, it's also testing
>> that it's being called correctly in a real* live system. You seem to be
>> advocating against functional tests as a concept?
>>
>> *certainly more real than a system involving mocking open() in a unit
>> test.
>>
>>> --
>>
>> --
>> Matt Wheeler
>> http://funkyh.at
>>
>
> _______________________________________________
> 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/20170509/2bedfd69/attachment.htm>