qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Store tests
Date Tue, 10 Nov 2009 03:41:27 GMT
2009/11/10 James Birdsall <jbird@microsoft.com>

> On Monday, November 09, 2009 12:41 PM, Alan Conway wrote:
> >On 11/09/2009 11:45 AM, Kim van der Riet wrote:
> >> It would be a good idea to standardize store tests if we can. If we can
> >> agree that no matter what store is used, the end-result from a client
> >> perspective would be the same, then tests would be fairly universal and
> >> can be run against any store module.
> >>
> >> All tests outlined below (which are based on some of the current async
> >> store tests) assume a clean broker start with the store module loaded
> >> (with no store content on disk) and stopping broker on conclusion for
> >> each test (which may or may not leave messages in the store) - so there
> >> needs to be some mechanism to clean up store artifacts between tests.
> >> However, if tests are carefully constructed, it may be possible to avoid
> >> a disk cleanup between tests by ensuring exchange and queue names do not
> >> overlap between tests. No test should leave the store in an
> >> unrecoverable state.
> >
> >The python broker tests framework I've been working on creates a separate
> >working directory for each test, all under a common directory so its easy
> to
> >clean up between test runs so there's no need to worry about conflicts
> between
> >tests.
> >
> >> Tests marked (SERVER-SIDE) may need to be run from the broker itself or
> >> on the same machine as the broker in order to gain access to store
> >> artifacts.
> >And they'd be easy enough to write in python.
> >
> >> Suggestions welcome.
> >The set below looks good. In particular I think the idea of having the
> tests be
> >based on user-observable outcomes is the right way to go.
> Tests for persistence providers came up a while back; I'm in the middle of
> writing some for the SQL-based provider that Steve Huston is working on. My
> test plan is more basic, since I'm new to AMQP and Qpid and don't have the
> detailed understanding of it yet, but even so my tests have shaken out a
> number of bugs. The test plan is 99% not specific to the provider; at some
> point I would like to try it against other providers, just to see what
> happens.
> The mailing list strips attachments and I don't have permissions to add a
> page to the wiki (I can't even LOOK at most of the testing pages!), so I
> will send the PDF to Kim directly. If anyone else would like to see it,
> please let me know!
Can you create a JIRA and attach the PDF to that?


> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message