Creating unit tests on the fly

Roy Smith roy at panix.com
Sun Apr 10 22:45:16 EDT 2011


In article 
<e2a1efe6-17bb-4d94-8fcc-b812b41f6b75 at d28g2000yqf.googlegroups.com>,
 Raymond Hettinger <python at rcn.com> wrote:

> I think you're going to need a queue of tests, with your own test
> runner consuming the queue, and your on-the-fly test creator running
> as a producer thread.
> 
> Writing your own test runner isn't difficult.  1) wait on the queue
> for a new test case. 2) invoke test_case.run() with a TestResult
> object to hold the result 3) accumulate or report the results 4)
> repeat forever.

OK, this is working out pretty nicely.  The main loop is shaping up to 
to be something like:

    def go(self):
        result = unittest.TestResult()
        while not self.queue.empty():
            route, depth = self.queue.get()
            test_case = self.make_test_case(route)
            suite = unittest.defaultTestLoader. \
                    loadTestsFromTestCase(test_case)
            suite.run(result)
   if result.wasSuccessful():
            print "passed"
   else:
            for case, trace in result.failures:
      print case.id()
      d = case.shortDescription()
      if d:
                    print d
      print trace
      print '------------------------------------'

It turns out there's really no reason to put the test runner in its own 
thread.  Doing it all in one thread works fine; make_test_case() passes 
self.queue to the newly created TestCase as part of the class dict, and 
one of the test methods in my BaseSmokeTest pushes newly discovered 
route onto the queue.  Perhaps not the most efficient way to do things, 
but since most of the clock time is spent waiting for the HTTP server to 
serve up a page, it doesn't matter, and this keeps it simple.

Thanks for your help!

PS: After having spent the last 6 years of my life up to my navel in 
C++, it's incredibly liberating to be creating classes on the fly in 
user code :-)



More information about the Python-list mailing list