title: unittest.py doesn't play well with trace.py - why?
body: <p>Wow.  I found out tonight that Python unit tests written using the <code>unittest</code> module don't play well with coverage analysis under the <code>trace</code> module.  Here's the simplest possible unit test, in <code>foobar.py</code>:</p>
  
  <pre><code>import unittest
  
  class Tester(unittest.TestCase):
      def test_true(self):
          self.assertTrue(True)
  
  if __name__ == "__main__":
      unittest.main()
  </code></pre>
  
  <p>If I run this with <code>python foobar.py</code>, I get this output:</p>
  
  <pre><code> .
  ----------------------------------------------------------------------
  Ran 1 test in 0.000s
  
  OK
  </code></pre>
  
  <p>Great.  Now I want to perform coverage testing as well, so I run it again with <code>python -m trace --count -C . foobar.py</code>, but now I get this:</p>
  
  <pre><code>----------------------------------------------------------------------
  Ran 0 tests in 0.000s
  
  OK
  </code></pre>
  
  <p>No, Python, it's not OK - you didn't run my test!  It seems as though running in the context of <code>trace</code> somehow gums up <code>unittest</code>'s test detection mechanism.  Here's the (insane) solution I came up with:</p>
  
  <pre><code>import unittest
  
  class Tester(unittest.TestCase):
      def test_true(self):
          self.assertTrue(True)
  
  class Insane(object):
      pass
  
  if __name__ == "__main__":
      module = Insane()
      for k, v in locals().items():
          setattr(module, k, v)
  
      unittest.main(module)
  </code></pre>
  
  <p>This is basically a workaround that reifies the abstract, unnameable name of the top-level module by faking up a copy of it.  I can then pass that name to <code>unittest.main()</code> so as to sidestep whatever effect <code>trace</code> has on it.  No need to show you the output; it looks just like the successful example above.</p>
  
  <p>So, I have two questions:</p>
  
  <ol>
  <li><p>What is going on here?  Why does <code>trace</code> screw things up for <code>unittest</code>?</p></li>
  <li><p>Is there an easier and/or less insane way to get around this problem?</p></li>
  </ol>