On Thu, 2012-03-29 at 12:56 +0200, Krzesimir Nowak wrote: > 2012/3/29 Patrick Ohly <[email protected]>: > > On Thu, 2012-03-29 at 10:44 +0200, Krzesimir Nowak wrote: > >> 2012/3/27 Patrick Ohly <[email protected]>: > >> > For example, running a command line operation is not tested. Support for > >> > it is implemented, but only without the output handling. Before adding > >> > that, the tests from the Cmdline unit tests should be incorporated into > >> > test-dbus.py. That way it can be verified that the tests work (because > >> > they fail initially with the new branch) and developing the feature > >> > becomes easier (because testing doesn't have to be manual). > >> > >> I started working on it yesterday. Just to be sure - do all of the > >> tests from syncevo/Cmdline.cpp have to be ported? > > > > Some might be genuine unit tests (exercise the Cmdline class and not so > > much the implementation behind it), those can stay in Cmdline.cpp. > > Everything which does real, functional testing of more than just the > > Cmdline class (and I think most of the tests fall into that category) > > should be extracted so that it can run with --disable-unittests and > > exercises the entire system, like a normal user would. > > > > Ok, before I port more tests I would like you to just have a look on > one I have ported (testSetupScheduleWorld). > https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/cmdline-tests > > I guess that you will want it to be done differently.
Yes, using Session.Execute() directly avoids (mostly in the negative sense) testing whether the "syncevolution" tool and the "syncevolution <-> syncevo-dbus-server" communication works. Better figure out how to invoke syncevolution and capture its output. Bonus points if later some tests can also be written which give data to syncevolution (interactive password requests). I wonder how valuable the inline encoding of config files really is (createFiles()). test-dbus.py copies plain files instead. That way the test-dbus.py remains smaller. On the other hand, editing tests now requires editing multiple files. What do you think? > GConf Error: Configuration server couldn't be contacted: D-BUS error: > Method "GetDatabase" with signature "s" on interface > "org.gnome.GConf.Server" doesn't exist Looks like a GNOME setup problem. Neither org.gnome.GConf.Server nor libgconf are used directly by SyncEvolution. > [DEBUG syncevo-dbus-helper 00:00:00] exception thrown at > ../../../projekty/cxx/syncevolution/src/syncevo/DevNullConfigNode.h:46 > [ERROR syncevo-dbus-helper 00:00:00] : virtual read-only configuration > node, cannot write property sync = two-way > [DEBUG syncevo-dbus-helper 00:00:00] terminating as requested by operation > [INFO syncevo-dbus-helper 00:00:00] terminating normally > [DEBUG 00:00:01] execute() helper call completed, > org.syncevolution.Server: : virtual read-only configuration node, > cannot write property sync = two-way Interesting. Attaching to syncevo-dbus-helper and capturing the stack backtrace would be useful. But before you rathole there, better focus on writing the tests against current master. That code should work and can serve as reference for the expected behavior (with sanity checks, of course - there might be bugs also in the old implementation). -- 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
