Ben Finney <[EMAIL PROTECTED]> writes: > Steven Bethard <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
