[TIP] mocking a file in /proc

[Gregory Salvan]

2) I would like to learn what is the standard way to deal with such
situations. If there is a "standard way" at all... I mean, what am I
supposed to do from the point of view of TDD?


I feel confusion about what I've said.
Let me be crystal clear: in the point of view of TDD *you never open a real
file to test something in python* ! never
This rely to python implementation and your aim is not to test python.

The common way to do this in TDD is to use dependency injection and
probably you'll see a strategy pattern emerging (or a partial one).


Out of TDD, you test what you want, it's a different practice with a
different purpose.



2017-05-09 16:36 GMT+02:00 Tim Ottinger <tottinge at gmail.com>:

> 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/35eb0a72/attachment.htm>