[Telepathy] twisted test question

Dafydd Harries dafydd.harries at collabora.co.uk
Wed Jan 28 23:48:46 PST 2009

Ar 27/01/2009 am 15:29, ysgrifennodd Jonathon Jongsma:
> As many of you are aware, I'm adding some test cases to telepathy-idle.  I have 
> a decent feel for the test infrastructure now, but I don't see any way to assert 
> that an event doesn't happen.  For instance, if you want to assert that a 
> dbus-signal is emitted, you can do things like:
> 	q.expect('dbus-signal', ...)
> but I don't see any way to specify that something shout NOT happen, maybe 
> something like:
> 	q.expect_not('dbus-signal', ...)
> or perhaps more usefully, something like:
> 	q.expect_many(EventPattern('foo'),
>          	      EventPattern('bar'),
> 	              ForbidEventPattern('baz'))
> that would require events 'foo' and 'bar' to happen but fail if event 'baz' occurs.
> Is there anything like that available?  Has anybody wanted to do something 
> similar and found a different way to achieve it?

If your event is never supposed to happen in the lifetime of the test, it
would make sense to extend the event queue API with a forbid() method.

A test is comparable to a regex of the form /a.*b.*c.../, where a, b, and c
are individual event patterns, and the string to be matched is the sequence of
events. (The expect_many() construct doesn't map very simply; for matching 2
events a, b, c it's equivalent to
/(a.*(b.*c|c.*b))|(b.*(a.*c|c.*a))|(c.*(a.*b|b.*a))/.) Forbidding d from
happening would be equivalent of replacing each ".*" with "[^d]*". It might
work, but I'd be worried about getting the boundaries of when d is not
supposed to happen wrong.

Another approach would be to have variants on expect(_many) that avoid the
".*" altogether: i.e. expect_total([a,b,c]) mapping to either /abc/
or /(a(bc|cb)|(b(ac|ca))|(c(ab|ba))/ (or maybe different variants for each).
Any extra events would cause an error. This also has the boundary problems.

Yet another approach would be to have variants on expect(_many) that returned
a list of any events you didn't explictly expect, but which happened in
between the ones you did. This also has the boundary problems.

Still another approach would be to check the events that happened after the
main test code had finished.

More information about the Telepathy mailing list