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