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 <[email protected]> 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 [email protected] http://lists.syncevolution.org/listinfo/syncevolution
