added data-stubbing to UnifiedAlchemyMagicMock

[miki725]

eventually settled on this API. seems the cleanest of all options I thought of.

some criteria which it needed to satisfy:

• has to be potentially aware of all criteria used within a single transaction (all method calls between .all() or .__iter__() in session which actually result some result)
• has to be graceful with criteria so things like .order_by(), .join() do not have to specified in order to match results
• order of method calls should not matter. .order_by() can be called first, etc

some options which I had:

option 1 - inline definitions next to mock methods with utility method

mock_session.query.with(Model).filter.with(Model.foo == 'bar').results([..])

implementing would of been pretty difficult since multiple states would need to be maintained. also usage just seems really strange

option 2 - passing data in __init__ as dict

UnifiedAlchemyMagicMock(data={
    mock.call.filter(): []
})

idea is nice but mock.calls are not hashable so cannot be used as dict keys. also would need some way to specify multiple methods

option 3 - passing data in __init__ as list of ([method, method]: [result]) tuples

UnifiedAlchemyMagicMock(data=[
    ([mock.call.filter(), mock.call.order_by()]: []),
])

that seems to solve many problems. since UnifiedAlchemyMagicMock already unifies various mathods, their order does not matter (although within each method the order of args does matter except filter and filter_by). also this allows gracefully ignore some methods such as order_by simply by not specifying it in the list of clause methods...

[miki725]

cc @shosca @milin what do you think about API? see description for more details

[coveralls]

Coverage remained the same at 100.0% when pulling e3375e4475b124bcba0f208fb068377aa544a7ab on stubbed-data into d1eef2b793b93fef4a8126004465587129f37026 on master.