[TIP] mocking a file in /proc

Tue May 9 11:02:18 PDT 2017

I tend to view TDD as orthogonal to whether you're doing functional,
integration or unit testing. In fact, I often write a failing
functional test to start, and then write a failing test at a lower
level.

As to whether functional tests are necessary: whenever you write a unit
test that mocks out interaction with an external system (whether using
actual mocks or just sample data), you're making an assumption about
how that external system will behave (in this case, the files
under /proc). The degree of functional testing necessary depends on how
confident you are in those assumptions. If you know that the values you
read from /proc will always be the same, then it probably suffices to
put those specific values in the tests without actually testing against
the real thing. On the other hand, if it's likely that different
systems will have different values in those files, or that those values
might change over time (say, due to different versions of the operating
system), then functional testing is useful to ensure that your
assumptions are still valid.

What I find most useful in that situation is trying to split the
tests: one set of potentially slow and hard-to-run tests that test the
assumptions you've made about the external systems, one set of fast
unit tests that uses those assumptions, and a small number of end-to-end
tests to make sure that you've wired the two parts of the system
correctly.

Michael

On Tue, 9 May 2017 19:18:30 +0200
Gregory Salvan <apieum at gmail.com> wrote:

> 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
> >>>
> >>