1:40 p.m.
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.
>