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.
_______________________________________________
Telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
