> The only problem with this kind of testing is, that we still don't really > have a good way to test trigger, as it is tied to external events. My idea > here was that I could add something like wiki edit consumer, and trigger > tasks off of that, making that one "triggering" edit from inside the > testsuite.
In my experience, some fedmsg notifications are quite delayed from time to time, easily by several hours. But I don't know if the delay is in actual fedmsg bus, or just in FMN (which I use to get notified on IRC). I suspect rather FMN. But if that turned out to be a fedmsg delay, that might make this approach impractical (or at least less reliable). So something to consider and possibly investigate. I think it would be better to fake the input data. Either by having our own fedmsg producer and/or bus (I don't know precisely how fedmsg works and how hard is to set up something like that), or by making some code adjustments in trigger that will allow us to bypass the fedmsg reception and replace it with our own fedmsg, but cover as much surrounding code as possible.
_______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
