Re: [SyncEvolution] writing unit tests for our new D-Bus API
On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote: dbus-monitor buffers its output and doesn't flush it when exiting, which means that output is lost. Stupid dbus-monitor. No solution :-/ dbus-monitor has broken SIGINT handling and no handling of SIGTERM. Because of its brokeness, distros patch this out of their dbus-monitor binaries. Here's a patch which fixes dbus-monitor. I'm not sure yet how useful catching a D-Bus log with dbus-monitor will be - we'll see... commit f6719df9e3a545acf8600970190d3bd89cfd390a Author: Patrick Ohly patrick.o...@gmx.de Date: Wed Oct 14 14:20:00 2009 +0200 dbus-monitor: fix for CTRL-C/SIGINT and SIGTERM CTRL-C/SIGINT had no effect because dbus_connection_read_write_dispatch() continues with poll() after an interrupted system call. This caused Debian and Ubuntu to remove the signal handling code since 1.1.1-1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414139 This patch solves the problem using brute force: a timeout of 500ms ensures that dbus_connection_read_write_dispatch() is left often enough to react to signals in a more or less timely manner. Nicer solutions are of course possible (custom main loop), but also more intrusive. In addition, this patch also catches SIGTERM. This is the default signal used by kill and Python's subprocess.terminate() and thus worth handling. diff --git a/tools/dbus-monitor.c b/tools/dbus-monitor.c index 873108b..03600b0 100644 --- a/tools/dbus-monitor.c +++ b/tools/dbus-monitor.c @@ -339,9 +339,15 @@ main (int argc, char *argv[]) exit (1); } - /* we handle SIGINT so exit() is reached and flushes stdout */ + /* we handle SIGINT and SIGTERM so exit() is reached and flushes stdout */ signal (SIGINT, sigint_handler); - while (dbus_connection_read_write_dispatch(connection, -1) + signal (SIGTERM, sigint_handler); + /* + * The signal alone won't get us out of dbus_connection_read_write_dispatch(), + * it seems to simply call poll() again. Check for termination every + * 500ms. + */ + while (dbus_connection_read_write_dispatch(connection, 500) !sigint_received) ; exit (0); -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] writing unit tests for our new D-Bus API
On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote: What do you think about this? As there were no cries of outrage, I went ahead and improved the test script. While extending the tests I already found different issues in the implementation: * Server.GetConfigs() missing * Session.Status and Session.Progress signal names instead of Session.StatusChanged and Session.ProgressChanged * Session status changed from queueing to running instead of going to idle first Currently the script is able to run a real sync via the D-Bus API, which can also be used to add more checks that progress reporting etc. works. Configuration of the script is still hard-coded. See the updated script and log message for details. I'll let it sit for a few days, so if someone else wants to work on it, feel free. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] writing unit tests for our new D-Bus API
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.o...@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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
