2012/4/13 Patrick Ohly <patrick.ohly(a)intel.com>:
On Do, 2012-04-12 at 15:59 +0200, Krzesimir Nowak wrote:
> > In the meantime I'll merge these changes into the ccs-pohly branch.
Branch updated and rebased, see ccs-pohly-cmdline.
> Some of the tests are implemented in following branch:
> Commits are not so informative - will do it later.
And they are also incomplete, aren't they? stdout and stderr from
running the command line tool are captured, but they are not checked
anywhere. Nor is the return code checked.
Forgot about the return code. stdout and stderr are captured in other
tests (like testPrintConfig - not yet pushed to my branch).
+def runSyncEvolution(argsstr, envstr):
+ return subprocess.Popen("env `dbus-launch` " + envstr + " sh -c
'trap \"kill $DBUS_SESSION_BUS_PID\" EXIT; syncevolution " + argsstr +
"'", shell = True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
It would be better to pass arguments as array to runSyncEvolution and
subprocess.Popen(). Same for the env. That avoids quoting issues:
+ argsstr = "--configure --sync-property \"proxyHost = proxy\"
+ envstr = "SYNCEVOLUTION_TEMPLATE_DIR=" +
os.environ["SYNCEVOLUTION_TEMPLATE_DIR"] + " XDG_CONFIG_HOME=" +
self.testdir + " HOME=" + self.testdir
Regarding the environment, better refactor the code that is used for
starting syncevo-dbus-server and use the same environment for both
Regarding the dbus-launch above, why is that necessary? test-dbus.py
must be running inside a valid D-Bus session. Quite the opposite,
launching another session probably prevents using the
syncevo-dbus-server which was already started in the outer D-Bus session
I guess it just worked for me. And those strange GConf errors
(probably used by some backend) stopped showing up.
> For now testTemplate is failing - I do not know whether this should be
> fixed in Cmdline or rather the test should be adapted to current
> behaviour. This place is marked as TODO.
I'll have a look.
I got it working in for-master/cmdline-output after forced update.
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.