-
Notifications
You must be signed in to change notification settings - Fork 18
Differences from the ruby version
has207 edited this page Mar 25, 2012
·
6 revisions
There are a number of differences in the Python implementation of Flexmock from its Ruby predecessor. This is not an exhaustive list, but I will try to keep these documented here.
- method names are strings instead of symbols (Python doesn't have symbols)
- all the redundant methods are left out to keep the API as lean as possible
- with is with_args -- silly Python parser won't let you name a method after a reserved word
- and_yield returns a generator
- multiple return values are not returned separately by default, they come back as a tuple unless you specify .one_by_one
- new_instances() overrides __new__ to return new instances
- flexmock(SomeClass) is roughly equivalent to flexmock(SomeClass).new_instances in Ruby (but it affects old instances too)
- When using chained methods and defining flexmock(Foo).should_receive('method1.method2.method3') followed by flexmock(Foo).should_receive('method1.method2.method4'), the second flexmock call effectively overrides the first since a new return chain is created on method1. This intuitively makes sense if the chained method definitions are properly considered shorthand for flexmock(Foo, method1=flexmock(method2=flexmock(method3=None))). The ruby version keeps track of all the intermediate objects and tries to do the right thing in the corner cases that will arise when you try to make the original definitions work. In the python version you'd have to do flexmock(Foo).should_receive('method1.method2').and_return(flexmock(method3=None, method4=None)) to achieve the desired effect.