Wed 24 Aug 2005
Wrote up the regression testing framework for the D-Bus python bindings. It is quite easy to add tests now and I have a few basic ones up. All one has to do is edit the test/python/test-service.py and test/python/test-client.py files to add a D-Bus transaction. If you don’t get back what you expected from the server raise an exception in test-client.py and the test will fail.
These tests will be run every time someone does a make check, so, if you have a complicated D-Bus Python application and don’t want me to break it I would suggest sending some patches to the tests. If the tests get complicated I can always split them up into seperate test bundles.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
August 24th, 2005 at 9:13 pm
Have you considered using the Python unit testing framework for the test-client.py implementation? It seems like it would be well suited for this kind of thing, and would continue to run tests after the first failure (i.e. it’d still fail, but you’d know if one test failed as opposed to all the tests after the failing one).
August 24th, 2005 at 9:20 pm
With make check you sort of want to stop when one test fails, fix it up and then go on. I wouldn’t object however is someone sent me a patch as long as it doesn’t make it any harder for people to implement tests.
August 25th, 2005 at 1:43 am
Currently in test-client.py, you have a number of tests:
* connecting to the session bus
* resolving an object on the session bus
* narrowing to a particular interface
* introspecting the object
* testing various ways of invoking methods on the object
* testing various inputs/outputs of methods on the object
With a test suite, you usually want to run all the tests, and see which ones fail. If you stop running tests after the first error, then you won’t know if the later tests pass.
The docs on the Python unit test framework are here:
http://www.python.org/doc/current/lib/module-unittest.html
The “basic example” page shows the common way to structure the tests.