Fudge, the python mock tool, goes 1.0! You can grab it with pip install -U fudge or directly from PyPI. This marks the end of a long incubation period where the community and I used Fudge in real world scenarios to see what worked and what didn't. I'm sure there are many more improvements to make but as of 1.0 I'm very satisfied with what we've accomplished. This is thanks to its small but vocal community of users, to all contributors and to everyone who pointed out flaws.
Fudge was inspired by Ruby's Mocha which was in turn inspired by jMock but Fudge does way less meta programming than Mocha and is not nearly as verbose as jMock.
What is special about Fudge? Fudge let's you declare how you want an object to behave. You use it in a test like this:
@fudge.patch('smtplib.SMTP')
def test_mailer(FakeSMTP):
# Declare how the SMTP class should be used:
(FakeSMTP.expects_call()
.expects('connect')
.expects('sendmail').with_arg_count(3))
# Run production code:
send_mail()
# ...expectations are verified automatically at the end of the test
If those expectations aren't met then a detailed traceback is raised in your test telling you what went wrong. What's powerful about this approach is that you, the developer, have to think about what the mock object should do. It's a very natural way to work. As a side effect, your tracebacks will often point directly to the culprit and there is no need for postmortem inspection like in mock or similar tools. You can read more about how Fudge compares to other tools here.
The major problem with Fudge 0.9 was that you had to manage setup and teardown
to ensure expectations would get verified. If these got out of order or
if you wanted to switch between functions and classes, it was cumbersome and fragile.
This is all fixed in Fudge 1.0 by the introduction of the @fudge.patch and @fudge.test decorators.
The @patch decorator is lifted from inspired by mock. I actually still use mock in many projects that
were already committed to mock before I joined them. By coincidence, this also makes it
easy to port your code from mock to Fudge if you want to :).
This change is backwards compatible but here's a guide for
migrating your old Fudge 0.9 code to 1.0 code. Note that
flexmock is another declaration-based mock library that solves the setup/teardown problem
but it does so by coupling itself to the test runner.
It's nice that there are so many mock testing tools to chose from in Python!
Also, rest assured that Fudge supports both Python 2 and 3 and has done since its 0.9.5 release. Enjoy.