1:38 a.m.
Hello!
We are getting to a point where the D-Bus API should be usable for the
GUI. The new code still needs to be tested, which is only possible by
adapting the sync-UI and/or writing Python scripts to call the API.
This is not a satisfactory situation. We should have the possibility to
run such scripted testing in a more organized fashion and eventually,
include it in our regular regression testing.
I've looked into possibilities to automate this using a Python testing
framework. I settled on the included "unittest" because in contrast to
"Nose" or "py.test" it is guaranteed to be available and seemed to do
the job.
Additional requirements were:
1. start and stop our D-Bus server automatically for each test
2. check for errors incurred inside the server during a test
(segfaults, memory leaks)
3. include information produced by server and dbus-monitor if a
test fails, to simplify offline debugging
4. run under a debugger for interactive debugging
I only have a partial solution for this, committed to "dbus-api" for
discussion. The new "test-dbus.py" still needs to be extended so that it
can be configured via command line parameters. Right now it only
supports the standard options of unittest.main() (see --help).
dbus-monitor buffers its output and doesn't flush it when exiting, which
means that output is lost. Stupid dbus-monitor. No solution :-/
Here's the commit message with more information:
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Oct 13 16:12:34 2009 +0200
D-Bus testing: use 'unittest' to write tests, watch syncevo-dbus-server
A special run() method ensures that the syncevo-dbus-server
is started for every single test. For this to work, the server
must print a single line right before it is ready to start.
The run() method checks the result of the D-Bus server and adds
its output to test failures. It also checks the return code, so
if syncevo-dbus-server ran under valgrind (not currently possible),
valgrind failures would show up.
The run() method also runs "dbus-monitor" in an attempt to log the
traffic on the D-Bus, but because dbus-monitor does not flush its
output upon receiving SIGINT, the output is currently lost. Pretty
useless...
It is possible to start syncevo-dbus-server under a debugger before
running the test. For this set "debugger = 'gdb'" at the top of
the file, then in the gdb prompt set breakpoints etc. before running
the server. It has to be stopped manually, too.
Such runtime options should be selected via the command line, which
is not possible yet. The existing tests are just a proof of concept.
The really interesting ones (actually checking the content of
configs or templates) still have to be written.
What do you think about this?
I think every developer should ensure that his new code is covered by at
least some tests. Then another developer should check the tests to
ensure that they are correct and complete.
Yongsheng, do you think you could do the first part for the code you
wrote? Jussi, could you do the second part? Yanshuang, do you think the
QA team could help out?
--
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.