On Thu, Jun 30, 2011 at 12:58 AM, Patrick Ohly <[email protected]> wrote:
> On Wed, 2011-06-29 at 13:16 -0700, Patrick Ohly wrote:
>> Hello Chris!
>>
>> One comment on your commit in the test-dbus branch:
>>
>> -----------------------------------
>> commit da74d2aa1b671c0794cd88a854e137ae93ee102a
>> Author: Chris Kühl <[email protected]>
>> Date:   Tue Jun 28 14:48:56 2011 +0200
>>
>>     test-dbus: Remove check for only one report.
> [...]
>> Which test has the problem with too many reports? Does it use its own
>> XDG root?
>
> I found that the TestSessionAPIsReal tests using the real config
> "dbus_unittest" failed when too many reports where stored. I don't know
> how this was meant to work; one possible solution is to configure that
> config so that at most one report is retained. I've changed test-dbus.py
> accordingly and also removed the mangling of the "database" property:
>
>    """ All unit tests in this class have a dependency on a real sync
>    config named 'dbus_unittest'. That config must have preventSlowSync=0,
>    maxLogDirs=1, username, password set such that syncing succeeds
>    for at least one source. It does not matter which data is synchronized.
>    For example, the following config will work:
>    syncevolution --configure --template <server of your choice> \
>                  username=<your username> \
>                  password=<your password> \
>                  preventSlowSync=0 \
>                  maxLogDirs=1 \
>                  backend=file \
>                  database=file:///tmp/test_dbus_data \
>                  databaseFormat=text/vcard \
>                  dbus_unittest@test-dbus addressbook
>                  """
>

Thanks, this worked for that issue. I've removed that commit from the
test-dbus branch now.

> This fixes two out of seven failures that I was seeing, after I merged
> Chris' fix for the templates.
>
> Here's a temporary analysis of the failure. I'll continue to look into it.
>
> FAIL: read templates
> Fails if the host has paired Bluetooth devices because they get included in 
> the list.
> Cannot be fixed easily.
>
> FAIL: a second session should not run unless the first one stops
> AssertionError: ['session /org/syncevolution/Session/12604096081309383605 
> idle', 'session /org/syncevolution/Session/2552452311309383604 done'] != 
> ['session /org/syncevolution/Session/12604096081309383605 idle', 'session 
> /org/syncevolution/Session/12604096081309383605 ready', 'session 
> /org/syncevolution/Session/2552452311309383604 done']
> "Ready" before "Done"? Might be harmless, need to check.
>
> FAIL: Executes a real sync with no corresponding config.
> AssertionError: dbus.UInt32(500L) != 10500
> "No such config" should be a local error, not a remote one. Must be fixed in 
> syncevo-dbus-server.

Ok. Good to know. I'm using memotoo for testing and assumed the test
was intolerant to remote configurations, thus my commit to the
test-dbus branch allowing error code 500. I'll remove that commit and
see If I can fix this.

>
> FAIL: set up auto sync, then check that server restarts
> AssertionError: '/tmp/local/libexec/syncevo-dbus-server' != 
> '/home/pohly/work/syncevolution/src/syncevo-dbus-server'
> Caused by a mix-up between paths: as long as syncevo-dbus-server is only once 
> in PATH, this doesn't occur.
>
> FAIL: master must detect a hanging child
> Sync succeeds although it shouldn't - timing changes?
>

Ok, thanks for the insight.

Would it be possible for you to make a step by step list of what you
do to set up your environment for testing? I think this might help us
find why we are getting different results for the "defaultPeer" issue,
for example.

Cheers,
Chris
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to