In article
,
Raymond Hettinger 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
Roy Smith writes:
> In article <87fwpse4zt@benfinney.id.au>,
> Ben Finney wrote:
>
> > I have found the ‘testscenarios’ library very useful for this:
> > bind a sequence of (name, dict) tuples to the test case class, and
> > each tuple represents a scenario of data fixtures that will be
In article <87fwpse4zt@benfinney.id.au>,
Ben Finney wrote:
> Raymond Hettinger writes:
>
> > 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.
>
> I have found the âtestsce
Raymond Hettinger writes:
> 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.
I have found the ‘testscenarios’ library very useful for this: bind a
sequence of (name, dict) tuples to th
On Apr 8, 12:10 pm, Roy Smith wrote:
> I can even create new test cases from these on the fly with something
> like:
>
> newClass = type("newClass", (BaseSmokeTest,), {'route': '/my/newly/
> discovered/anchor'})
>
> (credit
> tohttp://jjinux.blogspot.com/2005/03/python-create-new-class-on-fly.ht
I've got a suite of unit tests for a web application. There's an
(abstract) base test class from which all test cases derive:
class BaseSmokeTest(unittest.TestCase):
BaseSmokeTest.setUpClass() fetches a UR (from a class attribute
"route", which must be defined in the derived classes), and there'
