Monday 19 October 2009 15:08
Funk 0.2 has just been released -- you can find it on the Cheese Shop, or you can always get the latest version from Gitorious. You can also take a peek at Funk's documentation.
The most important change is a change of syntax. Before, you might have written:
database = context.mock()
database.expects('save').with_args('python').returns(42)
database.allows('save').with_args('python').returns(42)
database.expects_call().with_args('python').returns(42)
database.allows_call().with_args('python').returns(42)
database.set_attr(connected=False)
Now, rather than calling the methods on the mock itself, you should use the functions in funk:
from funk import expects
from funk import allows
from funk import expects_call
from funk import allows_call
from funk import set_attr
...
database = context.mock()
expects(database).save.with_args('python').returns(42)
allows(database).save.with_args('python').returns(42)
expects_call(database).with_args('python').returns(42)
allows_call(database).with_args('python').returns(42)
set_attr(database, connected=False)
If you want, you can leave out the use of with_args, leading to a style very similar to JMock:
from funk import expects
from funk import allows
from funk import expects_call
from funk import allows_call
...
database = context.mock()
expects(database).save('python').returns(42)
allows(database).save('python').returns(42)
expects_call(database)('python').returns(42)
allows_call(database)('python').returns(42)
To help transition old code over, you can use funk.legacy:
from funk.legacy import with_context
@with_context
def test_view_saves_tags_to_database(context):
database = context.mock()
database.expects('save')
One final change in the interface is that has_attr has been renamed to set_attr. Hopefully, the interface should be more stable from now on.
There's also a new feature in that you can now specify base classes for mocks. Let's say we have a class called TagRepository, with a single method fetch_all(). If we try to mock calls to fetch_all(), everything will work fine. If we try to mock calls to any other methods on TagRepository, an AssertionError will be raised:
@with_context
def test_tag_displayer_writes_all_tag_names_onto_separate_lines(context):
tag_repository = context.mock(TagRepository)
expects(tag_repository).fetch_all().returns([Tag('python'), Tag('debian')]) # Works fine
expects(tag_repository).fetch_all_tags() # Raises an AssertionError
Two words of caution about using this feature. Firstly, this only works if
the method is explicitly defined on the base class. This is often not the case
if the method is dynamically generated, such as by overriding
__getattribute__ on the type.
Secondly, this is no substitute for integration testing. While its true that the
unit test above would not have failed, there should have been some integration
test in your system that would have failed due to the method name change. The
aim of allowing you to specify the base class is so that you can find that
failure a little quicker.
If you find any bugs or have any suggestions, please feel free to leave a comment.
Topics: Funk, Mocking, Python, Testing
Monday 28 September 2009 17:42
Roll up, roll up! That's right folks, I've written a Python mocking framework.
Another mocking framework?
Yup. As for why, there are a few reasons.
The simplest is to see just how difficult it was to write a usable mocking framework. It turns out not to be all that difficult – I managed to write the core of the framework over a weekend, although plenty of time was spent tweaking and adding behaviour afterwards.
A somewhat better reason is that none of the existing Python mocking frameworks that I could find really did what I wanted. The closest I found was Fudge. My criteria were something like:
- Not using the record/replay pattern.
- Allowing the expected calls and their arguments to be set up beforehand.
- Allowing differentiation between the methods that have to be called, and methods that can be called.
So what's wrong with Fudge?
Fudge meets all of these expectations. So what went wrong?
Firstly, I found Fudge too strict on ordering. Imagine I have a TagRepository that returns me tags from a database. I want to mock this object since I don't want to make a database trip in a unit test. So, in Fudge, I would set up the mock like so:
@with_fakes
def test_gets_python_and_debian_tags():
tag_repository = fudge.Fake()
tag_repository.expects('with_name').with_args('python').returns(python_tag)
tag_repository.next_call().with_args('debian').returns(debian_tag)
# Rest of the test
This would require me to get the Python tag before the Debian tag – yet I really didn't care which method I called first. I'm also not a fan of the syntax – for the first expectation, expects is used, yet for the second expectation, next_call is used.
The second problem I had was that, if you only set up one expectation on a method, you could call it many times. So, with the example above, if you had only set up the expectation for the Python tag, you could get the Python tag any number of times, so long as you asked for it at least once.
I dislike this since, by adding a second expectation, we have now changed the behaviour of the first. This does not lend itself to being able to modify or refactor the test quickly.
Finally, Fudge used a global context for mocks. The ramification of this is that, when using the decorator @with_fakes, each test inherits the mocks set up for the previous test. For instance:
@with_fakes
def test_tag_is_saved_if_name_is_valid():
database = fudge.Fake()
database.expects('save').with_args('python')
tag_repository = TagRepository(database)
tag_repository.save('python')
@with_fakes
def test_tag_is_not_saved_if_name_is_blank():
tag_repository = TagRepository(None)
tag_repository.save('')
The second test above would fail since it does not save the Python tag to the database created in the first test. This seemed somewhat unintuitive to me, so I ended up rolling my own decorator. At the start of each test, it would remove all of the mocks currently set up so that I could start from a blank slate.
The other effect is that it makes it difficult to nest mock contexts – admittedly, something I rarely need to do, but it can be useful to make a quick assertion that requires some amount of mocking.
Okay, what does Funk do differently?
Let's take a look at how we'd write that first test using Funk:
@with_context
def test_gets_python_and_debian_tags(context):
tag_repository = context.mock()
tag_repository.expects('with_name').with_args('python').returns(python_tag)
tag_repository.expects('with_name').with_args('debian').returns(debian_tag)
# Rest of the test
The first difference is that using the @with_context decorator means that we get a context passed in. If you want to build your own context, you can do so simply by calling funk.Context().
Secondly, Funk doesn't care what order you call the two methods in.
Finally, even if you only set one expectation, Funk expects the method to be called once. Setting up further expectations will not affect the existing expectations.
Show me the code!
You can see the Git repository over on Gitorious, or grab version 0.1 from the Cheese Shop. Feel free to try it out, although the API isn't 100% stable yet. The source includes some documentation, but you might also want to take a look at some of the tests to get an idea of what you can do.
Topics: Funk, Mocking, Python, Testing