[SyncEvolution] server class + fork/exec dbus-server + command line testing

Patrick Ohly patrick.ohly at intel.com
Thu Mar 29 02:02:01 PDT 2012


On Thu, 2012-03-29 at 10:44 +0200, Krzesimir Nowak wrote:
> 2012/3/27 Patrick Ohly <patrick.ohly at 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 args
> parameter for session.Execute()? I have seen "client-test" to be
> passed in TestCmdline class, but it seems to be used nowhere in
> Cmdline anyway.

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
cases.

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.

-- 
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Open Source Technology Center               
Pützstr. 5                              Phone: +49-228-2493652
53129 Bonn
Germany




More information about the SyncEvolution mailing list