> Agreed. The problem is: how long do we keep checking that these signals > are not sent? Whatever duration we choose, there's always the > possibility that the faulty signal is sent one second after we stop > watching ;-} Yes, it's a real problem. Just with an experience data. I think a duration of a new sync process is enough. Due to previous profiling data, 5~6s is an option.
Cheers, Yongsheng > -----Original Message----- > From: Ohly, Patrick > Sent: Friday, November 20, 2009 5:25 PM > To: Zhu, Yongsheng > Cc: SyncEvolution > Subject: RE: [SyncEvolution] D-Bus Testing + TestSessionAPIsReal + > StatusChanged "done" multiple times > > On Fri, 2009-11-20 at 08:43 +0000, Zhu, Yongsheng wrote: > > > I'm not sure I understand. Because signals should not be sent in certain > > > situations, we don't need to check this? Isn't the conclusion exactly > > > the opposite? Because the test script needs to work with a potentially > > > buggy server, it must do as much checking as possible and be prepared to > > > report server failures gracefully. > > For a buggy server, it is possible. > > But I think a correct server should not. So my suggestion is that we should > > add at least one case to test this scenario: these signals should not be > > sent > > out. This could make sure that our server at least has no this kind of > > error. > > Agreed. The problem is: how long do we keep checking that these signals > are not sent? Whatever duration we choose, there's always the > possibility that the faulty signal is sent one second after we stop > watching ;-} > > > > I merged everything related to this into master, including the fix for > > > the StatusChanged "idle" problem. There are more patches pending in the > > > "pohly" branch, please let me know what you consider ready for merging. > > One question, in the patch 'syncevo-dbus-server: StatusChanged "idle" was > > not > sent', > > + loop.run() > > + expected = ["session " + self.sessionpath + " done", > > + "session " + sessionpath + " idle", > > + "session " + sessionpath + " ready"] > > + expected.sort() > > + DBusUtil.quit_events.sort() > > + self.failUnlessEqual(DBusUtil.quit_events, expected) > > I find expected and quit_events are all sorted. Don't we guarantee the > sequence? > > Not between Session.StatusChanged and Server.SessionChanged, which is > tested here. > > > 'progress' testing needs check the sequence problem. > > In this case, the semantic of the 'progress' events imply a certain > order. There are lots of TODOs in the test program related to > 'progress'. They are recorded, but there are no checks that they are > reasonable. > > > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
