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.
Also, I guess that I can pass any value to be under 0th index of
parameter for session.Execute()? I have seen "client-test" to be
passed in TestCmdline class, but it seems to be used nowhere in
Careful here. The main goal is to have real tests involving
syncevolution as frontend and syncevo-dbus-server as backend. That means
the test driver needs to invoke the syncevolution binary. Unit tests are
useful to check for specific corner cases quickly, but in general I
prefer to have realistic integration tests which include the corner
Putting this into test-dbus.py has the advantage that there is quite a
bit of infrastructure for setting up and monitoring syncevo-dbus-server
and for creating the right environment (XDG env variables, content of
these directories - see @property("snapshot")).
Invoking and monitoring an executable instead of making D-Bus calls will
require some plumbing.
Senior Software Engineer
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652