9:10 p.m.
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
2:12 p.m.
New subject: [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
7:56 p.m.
New subject: [SyncEvolution] Test cases design for DBus server: Status and Progress
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: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] 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
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
8:16 p.m.
New subject: [SyncEvolution] Test cases design for DBus server: Status and Progress
On Tue, 2009-12-01 at 08:56 +0000, Zhu, Yongsheng wrote:
['progressChanged' and 'StatusChanged' in DBusUtil]
If no objection, I'll implement it in this way.
Sure, go ahead. The recording of events in DBusUtil.events was meant to
be used for checking the result of a sync after the sync, but it is not
used yet and can be removed if it turns out to be of no value.
--
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.
6:47 p.m.
New subject: [SyncEvolution] Test cases design for DBus server: Status and Progress
Sure, go ahead. The recording of events in DBusUtil.events was meant
to
be used for checking the result of a sync after the sync, but it is not
used yet and can be removed if it turns out to be of no value.
I'm not trying to remove it. Instead, I also use it to record events.
6 patches are ready on the branch 'yongsheng'. Please help review them.
Cheers,
Yongsheng
> -----Original Message-----
> From: Ohly, Patrick
> Sent: Tuesday, December 01, 2009 5:17 PM
> To: Zhu, Yongsheng
> Cc: SyncEvolution
> Subject: RE: [SyncEvolution] Test cases design for DBus server: Status and
> Progress
>
> On Tue, 2009-12-01 at 08:56 +0000, Zhu, Yongsheng wrote:
> ['progressChanged' and 'StatusChanged' in DBusUtil]
> > If no objection, I'll implement it in this way.
>
Sure, go ahead. The recording of events in DBusUtil.events was meant
to
be used for checking the result of a sync after the sync, but it is not
used yet and can be removed if it turns out to be of no value.
>
> --
> 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.
>
4673
days inactive
4678
days old
syncevolution@synevolution.org
4 comments
2 participants
participants (2)
-
Patrick Ohly -
Zhu, Yongsheng