In DBusUtil.setUpListeners, two callbacks are registered as signal receivers of
StatusChanged and ProgressChanged.
However, subclasses of DBusUtil might need do its own operations when these 2
signals are received.
The motivation is that I must make sure that the sync is *really* running and
then abort and suspend the sync.
To solve this problem and reuse the code, I'd like to add two methods
'progressChanged' and 'StatusChanged' in DBusUtil, which are
called by the 2 callbacks of setUpListeners internally. And for those
subclasses, override them. Pseudo code is:
class DBusUtil
def progressChanged(self, *args):
pass
def statusChanged(self, *args):
pass
def setUpListeners(self, sessionpath):
def progress(*args):
...
self.progressChanged(args)
def status(*args):
...
self.statusChanged(args)
class TestSessionAPIsReal(unittest.TestCase, DBusUtil):
def progressChanged(self, *args):
...
def statusChanged(self, *args):
...
If no objection, I'll implement it in this way.
Cheers,
Yongsheng
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Zhu,
> Yongsheng
> Sent: Monday, November 30, 2009 11:13 AM
> To: Ohly, Patrick
> Cc: SyncEvolution
> Subject: Re: [SyncEvolution] Test cases design for DBus server: Status and
> Progress
>
> > Looks reasonable. I was wondering whether those tests which run a full
> > sync should be combined. Advantage: shorter overall runtime.
> > Disadvantage: the different aspects cannot be tested independently. Your
> > choice (that way I don't have to decide ;-)
> Yes, that's really alternative. But I'd prefer write independently to make us
> easy
> to track
> these failures and regressions in future
>
> Cheers,
> Yongsheng
>
> > -----Original Message-----
> > From: Ohly, Patrick
> > Sent: Friday, November 27, 2009 6:11 PM
> > To: Zhu, Yongsheng
> > Cc: SyncEvolution
> > Subject: Re: Test cases design for DBus server: Status and Progress
> >
> > On Fri, 2009-11-27 at 06:17 +0000, Zhu, Yongsheng wrote:
> > > I write some test cases design for GetStatus/StatusChanged signals and
> > > GetProgress/ProgressChanged signals.
> > > Please see the attachment.
> >
> > Looks reasonable. I was wondering whether those tests which run a full
> > sync should be combined. Advantage: shorter overall runtime.
> > Disadvantage: the different aspects cannot be tested independently. Your
> > choice (that way I don't have to decide ;-)
> >
> > > But it seems that it is hard to do checkings for
> > > GetProgress/ProgressChanged accurately.
> >
> > That's true. Basic sanity checking as you suggested (increasing
> > progress, etc.) looks reasonable.
> >
> > Regarding test-dbus.py in general: some method of controlling the
> > currently hard-coded global settings would be useful, together with
> > documenting them.
> >
> > I didn't do that initially because it wasn't sure how useful the script
> > and individual options are, but it seems to be useful, so let's make it
> > not just useful, but also nice.
> >
> > One option that I keep changing in the source often is
> > debugger = "gdb"
> > to enable an interactive debug session of the syncevo-dbus-server during
> > a test.
> >
> > The other option that at least needs to mentioned is the dependency on a
> > valid HTTP server configuration, currently hard-coded at
> > "scheduleworld_1".
> >
> >
> > --
> > Best Regards
> >
> > Patrick Ohly
> > Senior Software Engineer
> >
> > Intel GmbH
> > Open Source Technology Center
> > Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
> > 50321 Bruehl Fax: +49-2232-2090-29
> > Germany
>
> _______________________________________________
> SyncEvolution mailing list
> [email protected]
> http://lists.syncevolution.org/listinfo/syncevolution
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
