7:30 a.m.
On Thu, 2012-03-29 at 12:56 +0200, Krzesimir Nowak wrote:
2012/3/29 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Thu, 2012-03-29 at 10:44 +0200, Krzesimir Nowak wrote:
>> 2012/3/27 Patrick Ohly <patrick.ohly(a)intel.com>:
>> > 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-syncevolut...
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.