Python automatic testing: mocking an imported module?

[rocky.bernstein at gmail.com]

On Mar 27, 9:13 pm, "Chris Lasher" <chris.las... at gmail.com> wrote:
> On Mar 27, 6:18 pm, "Silfheed" <silfh... at gmail.com> wrote:
>
> > Heyas
>
> > So we have the following situation: we have a testee.py that we want
> > to automatically test out and verifiy that it is worthy of being
> > deployed.  We want our tester.py to test the code for testee.py
> > without changing the code for testee.py.  testee.py has a module in it
> > that we want to mock in some tests and in others use the real module.
>
> I think you mean "testee.py *imports* a module", rather than "has a
> module in it". Semantics but I was thrown off by this at first.
>
> Why not write tests for the module that testee.py imports (here called
> "foo.py")? If you write out the tests and foo.py passes to spec, then
> you should feel confident it will work correctly with testee.py. Never
> trust it; always play paranoid coder, but feel comfortable enough
> using it.
>
> After all, why should you feel comfortable using modules in the
> standard library? Nobody guarantees bugs don't still lurk in there
> (heck, c.l.p just found one inpdbtoday),

A slight correction. At present it looks like the bug is in Python,
and its handling after setting the current frame's f_lineno when it
refers to byte code offset 0, not pdb. And if you scan c.l.p for
another oddity in pdb with respect to tracebacks, there is possibly
another bug in Python (not strictly pdb).

> however, they have unit
> tests out the wazzoo that demonstrate, to the best of our knowledge,
> the module works to spec.

Actually, as far as I know pdb *doesn't* have any unit tests! (pydb
does though ;-)

But all this nit-picking aside, I do agree with what you have to say
most whole heartedly. (And I'd say maybe a couple more unit tests for
Python to cover these bugs are in order.)

> If that approach is good enough for the
> standard library, wouldn't it be good enough for you?
>
> Chris