4:43 p.m.
Hi,
Now my question is: should the CPPUnit-based tests be replaced by
Python/D-Bus ones? The advantage is that we only have to maintain the
tests once, possibly in some easier form. The disadvantage is that
without D-Bus enabled, that test doesn't work, and that we haven't
integrated the D-Bus tests into our nightly testing.
Yes. Another thing is that I
think moving current test cases from CPPUnit-based
also need much work to do. But I'm inclined to move. Because this could also make
us maintenance and write new cases easier.
Do ' CPPUnit-based tests' include interoperability tests with servers?
Cheers,
Yongsheng
> -----Original Message-----
> From: syncevolution-bounces(a)syncevolution.org
> [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
> Sent: Friday, November 13, 2009 3:56 PM
> To: SyncEvolution
> Subject: [SyncEvolution] configuration testing
>
> Hello!
>
> Yongsheng has added some tests of the Session.Set/GetConfig() API calls
> to test-dbus.py and I merged them into master. These tests cover the
> API, but not whether the complete configuration tree looks exactly right
> down to every single property.
>
> The CPPUnit Cmdline test in src/syncevo/Cmdline.cpp covers these
> details. This implies extra work whenever new properties are added,
> because the reference configs must be updated as well. Being written in
> pure C++ with no external reference files, this comparison is kind of
> cumbersome.
>
> Maintaining the tests is worthwhile. I had not run the test while
> working on the new server config properties and promptly introduced some
> flaws:
>
> commit 4135afb8bc2b07730a05d679ebf8e6bd7ee2dde5
> Author: Patrick Ohly <patrick.ohly(a)intel.com>
> Date: Thu Nov 12 21:19:03 2009 +0100
>
> server config: fixed tests and code for new config options
>
> The Cmdline tests hadn't been updated together with adding the
> new options and therefore failed. New properties must be added
> to the reference config m_scheduleWorldConfig and new internal
> properties also to the props list in testOldConfigure.
>
> While checking the test failures, the following problems were found
> and fixed:
> - "adminData" property name was used for both sync and source
property.
> The sync property stores Synthesis device information and was
> renamed to "deviceData" to avoid confusion. SyncConfig API calls
> renamed accordingly. Property instance now follows syncProp* naming
> convention.
> - The source "adminData" property was not declared as
"hidden"
> and therefore showed up in the user-visible config.ini files
> and --print-config output. The real value set/get in SyncSourceAdmin
> was done correctly via the m_hiddenNode.
>
> But maintaining the tests might be easier as part of the Python script.
> We have regular expressions and can call external commands more easily.
>
Now my question is: should the CPPUnit-based tests be replaced by
Python/D-Bus ones? The advantage is that we only have to maintain the
tests once, possibly in some easier form. The disadvantage is that
without D-Bus enabled, that test doesn't work, and that we haven't
integrated the D-Bus tests into our nightly testing.
>
>
> --
> 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.
>
>
> _______________________________________________
> SyncEvolution mailing list
> SyncEvolution(a)syncevolution.org
> http://lists.syncevolution.org/listinfo/syncevolution