Re: Testing with concurrent sessions

Hi,

Kevin Grittner wrote:
> Based on Andrew's suggestion, I changed line 276 to:
>
> args=['psql', '-A', '--pset=pager=off',

That looks like a correct fix for psql, yes. Thanks for pointing that
out Andrew.

Other processes might be confused by (or at least act differently with)
a PAGER env variable, so that still needs to be cleared in general.

> I now get 5 of 6 tests succeeded (83.3%), processed in 18.5 seconds.

That's perfect. The one test that fails is expected to fail (another
thing dtester doesn't support, yet). The serialization code you write
should finally make that test pass ;-)

> I do want to expand the tests quite a bit -- do I work them all into
> this same file, or how would I proceed? I think I'll need about 20
> more tests, but I don't want to get in the way of your work on the
> framework which runs them.

Well, first of all, another piece of the missing manual: there are
BaseTest and SyncTest classes. Those based on BaseTest runs within the
event loop of the twisted framework, thus need to be written in the very
same asynchronous fashion. Mostly calling async methods that return a
Deferred object, on which you may addCallback() or addErrback(). See the
fine twisted documentation, especially the part about "Low-Level
Networking and Event Loop" here:

http://twistedmatrix.com/documents/current/core/howto/index.html

The SyncTest is based on BaseTest, but a new thread is created to run
its run method, passing back its results to the main event loop when
done. That allows you to call blocking methods without having to care
about blocking the entire event loop.

However, it makes interacting between the two models a bit complicated.
To call an async function from a SyncTest, you need to call the syncCall
method. The separate thread then waits for some callback in the main
event loop.

Both have their own set of caveats, IMO.

I'm not sure about how to organize the tests and ongoing development of
the framework. I've already broken the Postgres-R tests with dtester-0.0.

Maybe we put up a git branch with the dtester patches included? So
whenever I want to change the framework, I can check if and how it
affects your tests.

Regards

Markus