When I first started doing test-driven development as a PHP coder, our development shop used Marcus Baker's excellent SimpleTest framework. I liked it a lot. Since then I've used unit test frameworks in C, Perl, Java, and Python, and SimpleTest is still my overall favorite in any language.
As I became more obsessed with interested in
automated testing, however — reading books and blog articles,
experimenting with new testing patterns, getting xUnit tattoos
— I sometimes felt frustrated. Often I would want to write
some kind of test in the framework and language, but one or both was
just not powerful enough to express the idea cleanly.
It wasn't until I started coding a lot in Python that the cause hit me. Most xUnit frameworks, particularly if they provide good mock objects, are more than adequate in themselves to support any testing pattern I could come up with. SimpleTest certainly is. The problems I ran into came from the language itself...
Read more about how a language's features affect the tests you write in the full version of High-level Language Features and Testing
4 comments:
I highly recommend that you check out mocker. mocker uses monkey patching to allow isolation of the functionality under test without the unnecessary complexity of api parametization.
The pymock package is also an option, though its error messages are less than helpful in diagnosing test failures.
Thanks for pointing it out. I had seen mocker mentioned on the TIP (testing-in-python) mailing list but have not really checked it out yet.
Regarding the test's adding complexity to the class being tested itself... yeah, that test had been added almost experimentally. It turned out to be good enough, and did not add a great deal of complexity, so I didn't bother changing it. But I definitely agree that it is cleaner to use a mocking tool. When we update it for the next product release, we will probably do that.
On the plus site, even though it pollutes the namespace, allowing the mock function to be specified in the URL is easy to quickly understand, which comes through in this essay.
As one who has been down the mock path before, be careful. You are in essence building a new subsystem that scales linearly with your application in terms of complexity and maintenance. I tend to use them only when there are no viable alternatives now.
john -
I'm not clear what you mean by 'new subsystem' or 'scales linearly' since mocking in a dynamic language like Python has very little overhead. The initial and ongoing maintenance costs of mocking out dependencies in tests are far lower than writing functionality that allows dependency substitution as part of the api. I'm curious, was your experience in a static language like Java, and how do you write unit tests that isolate code from dependencies if not with mocks?
Post a Comment