[Zope-Coders] Help with Unit Testing: safe imports

[Jeremy Hylton]

>>>>> "TS" == Tres Seaver <tseaver@zope.com> writes:

  TS> On Mon, 2002-08-19 at 10:01, Guido van Rossum wrote:
  >> > Python's own 'unittest.py' fails silently if the test module
  >> > bails with import errors.
  >> >
  >> > Successful import of the module-under-test should *not* be
  >> > assumed by the test module..
  >>
  >> I don't understand this.  Can you describe a scenario in more
  >> detail?

  TS> Constructing a suite of tests for an entire package is tricky:
  TS> what is the framework supposed to do if it encounters a module
  TS> which looks like a test (has the correct name, imports unittest,
  TS> etc.) but which raises an ImportError at module scope?  

Then the tool running the tests should report this as a failure.  I
think the the problem, dear Tres, lies not in our tests, but in our
tools.  <wink>.

  TS> The tests which *should* have been run are unavailable, due to
  TS> the partial import, so the reporting machinery can't log them as
  TS> failed tests.  The execution environment *may* try to report the
  TS> problem, but the "standard" ones do not do so.  For instance,
  TS> with module-scope imports, the stock unittestgui.py will show a
  TS> "green bar", with a reduced number of passing tests.

I'd report this as a bug on unittestgui.py.

  TS> The idiom I propose (import the module-under-test only within
  TS> the context of 'testFoo' method) has netiher disadvantage:
  TS> import errors are caught and reported as test failures, without
  TS> any need for additional reporting machinery.

But it makes writing the tests more tedious because they have to
include lots of repetitive boilerplate.  If the boilerplate were truly
necessary that would be okay.  I live with Py_INCREF() and Py_DECREF()
after all.  But we can just fix the tools.

Jeremy