On 08:27 pm, gu...@python.org wrote:
On Fri, Feb 12, 2010 at 12:20 PM, <exar...@twistedmatrix.com> wrote:
The idea is that you're declaring what the tests need in order to
work.
You're not explicitly defining the order in which things are set up
and torn
down. �That is left up to another part of the library to determine.
One such other part, OptimisingTestSuite, will look at *all* of your
tests
and find an order which involves the least redundant effort.
So is there a way to associate a "cost" with a resource? I may have
one resource which is simply a /tmp subdirectory (very cheap) and
another that requires starting a database service (very expensive).
I don't think so. From the docs, "This TestSuite will introspect all
the test cases it holds directly and if they declare needed resources,
will run the tests in an order that attempts to minimise the number of
setup and tear downs required.".
You might have something else that breaks up the test run across
multiple
processes and uses the resource declarations to run all tests
requiring one
thing in one process and all tests requiring another thing somewhere
else.
I admire the approach, though I am skeptical. We have a thing to split
up tests at Google which looks at past running times for tests to make
an informed opinion. Have you thought of that?
You might have still something else that wants to completely randomize
the
order of tests, and sets up all the resources at the beginning and
tears
them down at the end. Or you might need to be more memory/whatever
conscious than that, and do each set up and tear down around each
test.
How does your code know the constraints?
To be clear, aside from OptimisingTestSuite, I don't think testresources
implements any of the features I talked about. They're just things one
might want to and be able to implement, given a test suite which uses
testresources.
The really nice thing here is that you're not constrained in how you
group
your tests into classes and modules by what resources you want to use
in
them. You're free to group them by what they're logically testing, or
in
whatever other way you wish.
I guess this requires some trust in the system. :-)
Jean-Paul
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
