5:12 p.m.
Hello everyone,
I'm testing the Syncevolution 1.0 beta 2 (I haven't had a chance to grab
beta 3 yet) using the scratchbox emulator environment, preparing to
trust data to it.
My intent is to run the sync evolution client on an N900 and
syncevolution HTTP server on my desktop.
The HTTP Server Howto on the wiki says that the HTTP server is not the
intended use case and that the Bluetooth sync direct is the more well
tested scenario.
In what way is it more well tested?
I see there are about 450 CPPUnit tests...very nice.
Are all the same tests that are run for Bluetooth sync testing
also run for the HTTP server sync scenario?
As I understand it the key differences in the two scenarios are the HTTP
server written in python (it's code looks concise and
clean) and the evolution dbus server (also used in the Bluetooth
scenario?).
Am I correct?
Anything else I should be considering in my evaluation?
--Jeff
2:31 p.m.
On Sat, 2010-04-24 at 23:12 +0100, Jeffrey Perry wrote:
My intent is to run the sync evolution client on an N900 and
syncevolution HTTP server on my desktop.
The HTTP Server Howto on the wiki says that the HTTP server is not the
intended use case and that the Bluetooth sync direct is the more well
tested scenario.
In what way is it more well tested?
Intel QA runs tests with Bluetooth sync. They don't test the HTTP
server. We (= developers) could and should test the SyncEvolution HTTP
server like we do with other SyncML servers in the nightly testing, but
we haven't set that up yet.
I see there are about 450 CPPUnit tests...very nice.
I'm not sure how you counted those. What we have and use a lot is the
automated testing of SyncEvolution as client with various third-party
HTTP SyncML servers.
Are all the same tests that are run for Bluetooth sync testing
also run for the HTTP server sync scenario?
Not yet. The same tests could be used for both, but they need be
parameterized differently (many phones are too dumb to handle the same
data as SyncML servers). I'm also not sure how to integrate phone
testing with the nightly test runs - place all phones next to the server
in the machine room?! Not possible right now, with the server in a
remote location ;-}
As I understand it the key differences in the two scenarios are the
HTTP
server written in python (it's code looks concise and
clean) and the evolution dbus server (also used in the Bluetooth
scenario?).
The SyncML server is indeed the same. Who initiates the connection and
what transport is used is the main difference, see
http://syncevolution.org/development/direct-synchronization-aka-syncml-se...
\
--
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:16 p.m.
On Sun, 2010-04-25 at 21:31 +0200, Patrick Ohly wrote:
On Sat, 2010-04-24 at 23:12 +0100, Jeffrey Perry wrote:
> My intent is to run the sync evolution client on an N900 and
> syncevolution HTTP server on my desktop.
>
> The HTTP Server Howto on the wiki says that the HTTP server is not the
> intended use case and that the Bluetooth sync direct is the more well
> tested scenario.
>
> In what way is it more well tested?
Intel QA runs tests with Bluetooth sync. They don't test the HTTP
server. We (= developers) could and should test the SyncEvolution HTTP
server like we do with other SyncML servers in the nightly testing, but
we haven't set that up yet.
When the HTTP server configuration is tested, which tests are run?
My intent is to avoid testing manually anything you may have covered
with automated tests,
> I see there are about 450 CPPUnit tests...very nice.
I'm not sure how you counted those. What we have and use a lot is the
automated testing of SyncEvolution as client with various third-party
HTTP SyncML servers.
The readme says to run client-test with no params to get a list of
tests... I piped it to wc -l and learned that there are about 450 tests
listed..
> Are all the same tests that are run for Bluetooth sync testing
> also run for the HTTP server sync scenario?
Not yet. The same tests could be used for both, but they need be
parameterized differently (many phones are too dumb to handle the same
data as SyncML servers). I'm also not sure how to integrate phone
testing with the nightly test runs - place all phones next to the server
in the machine room?! Not possible right now, with the server in a
remote location ;-}
Sounds like you can run all the phone client tests against the HTTP
server. Do you do this ?
1:50 a.m.
On Mon, 2010-04-26 at 00:16 +0100, Jeff wrote:
On Sun, 2010-04-25 at 21:31 +0200, Patrick Ohly wrote:
> On Sat, 2010-04-24 at 23:12 +0100, Jeffrey Perry wrote:
> Intel QA runs tests with Bluetooth sync. They don't test the HTTP
> server. We (= developers) could and should test the SyncEvolution HTTP
> server like we do with other SyncML servers in the nightly testing, but
> we haven't set that up yet.
>
When the HTTP server configuration is tested, which tests are run?
Various SyncML semantic related tests (different sync modes,
update/delete/add). Large items. Sending various items to the server and
back, then check for data loss ("testItems", test data is in
test/testdata). For a full list you would have to look at the source.
My intent is to avoid testing manually anything you may have covered
with automated tests,
If you want to maximize the bang for the buck, then focus on the data
and properties that you want to have synchronized. We might not have
that covered by our tests.
> > I see there are about 450 CPPUnit tests...very nice.
>
> I'm not sure how you counted those. What we have and use a lot is the
> automated testing of SyncEvolution as client with various third-party
> HTTP SyncML servers.
>
The readme says to run client-test with no params to get a list of
tests... I piped it to wc -l and learned that there are about 450 tests
listed..
That ends up counting tests multiple times, as they are parameterized:
each test runs once for each data source alone, then also with all
sources enabled. For historic reasons, they are also enabled in two
different orders. This used to make a difference when using the Funambol
engine, not sure whether it still has an effect with Synthesis as
engine.
> > Are all the same tests that are run for Bluetooth sync
testing
> > also run for the HTTP server sync scenario?
>
> Not yet. The same tests could be used for both, but they need be
> parameterized differently (many phones are too dumb to handle the same
> data as SyncML servers). I'm also not sure how to integrate phone
> testing with the nightly test runs - place all phones next to the server
> in the machine room?! Not possible right now, with the server in a
> remote location ;-}
>
Sounds like you can run all the phone client tests against the HTTP
server.
In principle, yes, although it is more the other way around: the tests
were originally written for HTTP servers, now they can be reused for
phones.
Do you do this ?
We run tests against HTTP servers regularly, but not yet against phones.
--
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.
3930
days inactive
3932
days old
syncevolution@synevolution.org
3 comments
3 participants
participants (3)
-
Jeff -
Jeffrey Perry -
Patrick Ohly