[TIP] mocking a file in /proc

[Tim Ottinger]

I think that functional tests are fine, but they don't replace microtests.
Microtests are fine, too but they don't replace functional tests.
Both of those are great, but don't replace humans when it comes to matters
of taste, experience, and judgment. ;-)


On Tue, May 9, 2017 at 9:35 AM Tim Ottinger <tottinge at gmail.com> wrote:

> 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/8bcb7565/attachment-0001.htm>