PEP 299 and unit testing

[Ben Finney]

Ben Finney <bignose+hates-spam at benfinney.id.au> writes:

> Steven Bethard <steven.bethard at gmail.com> writes:
> 
> > Ben Finney wrote:
> > > What it doesn't allow is for the testing of the 'if __name__ ==
> > > "__main__":' clause itself. No matter how simple we make that,
> > > it's still functional code that can contain errors, be they
> > > obvious or subtle; yet it's code that *can't* be touched by the
> > > unit test (by design, it doesn't execute when the module is
> > > imported), leading to errors that won't be caught as early or
> > > easily as they might.
> > 
> > You could always use runpy.run_module.
> 
> Thanks! I was unaware of that module. It does seem to nicely address
> the issue I discussed.

Thinking about it further: I don't think it does address the issue.

Running the *entire* module code again in a single step (as
'run_module' seems to do) would happily overwrite any instrumented
faked attributes of the module that were inserted for the purpose of
unit testing, rendering it useless for unit test purposes.

The issue here is that there is an irreducible amount of functional
code inside the module that cannot be unit tested without running the
entire program with all its side effects.

PEP 299 promises to make that specific small-but-significant code
become an implementation detail in the language runtime, which would
mean it would no longer be prone to errors in the modules themselves,
and thus no longer the topic of a unit test on those modules. I think
100% statement coverage is not possible in Python programs without
this, or something that achieves the same thing.

-- 
 \           "We spend the first twelve months of our children's lives |
  `\          teaching them to walk and talk and the next twelve years |
_o__)        telling them to sit down and shut up."  -- Phyllis Diller |
Ben Finney