testresources: fresh blood
Last weekend I spent a bunch of timing hacking on testresources with Rob over at Chris's place. testresources is an extension to unittest that allows tests to specify the resources they use declaratively, so that these resources can be cleanly shared between tests. On Saturday, we talked a bit about direction and decided on some goals. On Sunday, I got busy.
The idea isn't particularly new: zope.testing has had "layers" for a long time. The key differences between testresources and Zope layers are:
- You can use more than one TestResource. You can only use one layer. Allowing tests to specify many resources makes it easier to use only the resources that you need, which in turn makes for a faster test suite.
- A test that uses testresources can be used independently of other testresources machinery. With layers, you pretty much need the whole shebang. This means that you can use testresources with trial, bzr, nose, tribunal or unittest.TextTestRunner.
- Layers have magical inheritance stuff. testresources has no magic.
- Layers do some work in subprocesses to accommodate some setUps that can have no tearDown. testresources doesn't know what a process is.
testresources itself is somewhat old. Rob hacked up the first version about three years ago and little has happened to it since. I've always agreed with the approach, but have also had a few qualms about implementation details that made me reluctant to use it or to recommend it. Now, it's well on its way to being something that I can trust and perhaps, love.
If you are interested, check out my branch or at least flick through the TODO file.
posted by jml @ 11:11 AM
2 Comments
2 Comments:
I thought I'd give a look at the testresources code. I've peeked at it before, and I'm generally interested in both testresources and your pyunit3k work.
Some quick comments:
1) There is a 'test_all.py' file in the root directory, but running it fails because the actual library is under 'lib/'. So you have to do something like "PYTHONPATH='lib' ./test_all.py" which seems a bit odd.
2) In grabbing pyunit3k, I figured I'd run *its* test suite as well. However that seems to depend on 'Zope' being installed. Which is a rather huge dependency for a small library. Is it truly dependent? Is it only the test suite? Could you something like the bzr 'Feature' work to make it a soft-dependency? (Test if it is available, else skip and warn)
Thanks for the comments John.
1) The way to run the testresources tests is 'make check'. I guess test_all can be tweaked to do PYTHONPATH setup.
2) The dependency is on zope.interfaces -- available separately from the main zope. I guess I don't really need to use it, and could use an abstract class instead.
Post a Comment
<< Home