On Mon, 2009-11-23 at 12:26 +0000, Chen Congwu wrote:
I have just enabled syncing with Nokia 7210c (Symbian S40 5th
works basically well with contacts(vcard 2.1), calendar(vcalendar),
todos(vcalendar) and memo(text/plain) (Server alerted two-way sync).
However I haven't conducted more extensive testing yet. I am
asking ideas for
automate the test process.
I fear that much of testing with phones will be manual. We might be able
to come up with something automatic for specific phones, but is that
worth the effort?
I think we have to base automated testing on what we except all phones
* one database for each data category
* sync with one server
At this scenario, SyncEvolution on Moblin acts as SyncML Server which
the sync with a Nokia phone. The "two client based client-test" mostly will
work here because a Nokia phone typically don't have mutliple profile support
(There is only "PC Suite" for Nokia PC Suite usage). Therefore emulating two
servers at PC side will likely not work.
Adding item on PC and SyncEvolution on PC init "server alerted two-way sync"
with phone, how can we reliably detect the item is really accepted at phone
Sync the phone with another server will not work because the phone doesn't support
What I can think of is:
a) Hacking on the Phone side so that it can work with multiple servers (or
emulation?) Not sure wheather it works.
b) Use Refresh-from-Server sync with the same server (This is very limited).
"Refresh-from-server", not "refresh-from-client"? I would test data
conversion like this:
* send items to device
* retrieve back from device, either via "refresh-from-client" or
wiping out data on the server + slow sync
This looks useful and doable to me. As with HTTP SyncML servers,
verification that both sides have the same semantic interpretation of
the data is a manual task.
We can't do change tracking testing this way with phones. To cover this
aspect in our server, we can test with multiple SyncEvolution clients.
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.