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.