[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.