Ian Bicking wrote:
Well, I made my first commit. It's not terribly impressive, just the
beginnings of some testing. It's in sugar.testing.mockdbus, and
sugar/presence/test_presence.txt.
After writing the test, I realized the client interface for presence
is really boring and probably not worth testing. I'll try again with
the server/service site, which may require mocking out some more parts
of dbus.
Yeah the service is the interesting part to test.
Another thing that comes up is the test infrastructure, i.e., how we
run tests. There's a couple options:
* We set up tests using unittest. We collect all the tests manually
(with lots of imports) and have a runner that runs them all. And then
we start hacking in various ways to select individual tests (e.g.,
only tests that run quickly, only tests of a certain portion of the
codebase). This works. It's annoying. It only uses the stdlib.
* We use a test runner that does this for us. This is what I'd
recommend. I used nose for this (http://nose.python-hosting.com/) and
I like it well enough. It requires a bit of fiddling to get it to
find all the tests you want it to find, which we'd probably put into a
shell script (also to fix up PYTHONPATH, e.g., to use the sugar
checkout).
If we use nose, we also probably need to install setuptools, and the
jhbuild has to be extended to include these. If I try to fix the
#!/usr/bin/python lines, I can probably try to add these at the same
time.
The test runner solution make sense to me as long as we can make it
"just work" (i.e. integrate it with jhbuild, no fiddling etc).
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
