Amazing talk! Really good explained, entertaining, and useful. "Mock where the object is used", is a very good practical advice! Kudos to the speaker, really superb!
11:12 - Scope tier -- Context Manager - duration is a partial life of a function -- Function decorator - duration is the entire life of a function -- Class decorator - duration is the entire life of all functions inside the class
Thank you! Lisa. Your presentation is succinct, clear and engaging; illustrations and examples are simple and to the point. I was new to patch and this really help me out a lot.
13:05 - It's recommended to use Context Manager for built-in functions 14:00 - Remember that a decorator creates a MagickMock object. It must be passed as an argument into the tested function. 14:39 - Yes, decorators can be stacked. However this is at the expense of DRY. 14:53 - in `setUp`, your patches can be started. You can then stop them all in `addCleanup` if a test goes bad before `tearDown` happens.
6:50 - Target must be importable -- patch auto-imports the target for you 7:30 - Don't patch where the function is declared, but where it is referenced 8:42 - If you import a function from a module: Use the importing module's name to target the function instead of the imported module. This is because the importing module's lookup table contains the function 9:36 - If you import an entire module: Use the imported module's name to target the function instead of the importing function.
Amazing explanation, especially showing what really happens under the hood... Been struggling with finding good documentation on mocking from the past few days and dunno how i missed this
I usually prefer to patch using either a context managers or manual start/stop. I'm not really a fan of the decorator version, because they add arguments to test classes, which is just really annoying to work with and because they don't allow you to share the mocking config as easily as the context managers and manual start/stop. Using context manager is also a lot more precise because it makes it really obvious which line of the test function actually requires the patched call. If only one line in the test actually requires patch, then just wrap that line on the context manager, and nothing else. Manual start/stop is great when you want to totally ignore a dependency. Usually helpful for patching out external calls that is slow or have side effects and failure modes you don't really want to deal with.
There's one crucial thing missing for me - if I patch it in context manager scope - how can I refer to the mock object? how can I assert how many times was it called? I see mock_* object in two other cases (method and class scope) but I can't see it in CM scope
Amazing talk! Really good explained, entertaining, and useful.
"Mock where the object is used", is a very good practical advice!
Kudos to the speaker, really superb!
this is the clearest explanation of patching I've found online
11:12 - Scope tier
-- Context Manager - duration is a partial life of a function
-- Function decorator - duration is the entire life of a function
-- Class decorator - duration is the entire life of all functions inside the class
What's going on, her ability to explain things blew my mind !!
The best talk of PyCon 2018!
Very good video and worth the time watching. Much clearer than Python documentation.
Great talk Lisa! You have addressed the most common problem that the patchers usually confused with
Thank you! Lisa. Your presentation is succinct, clear and engaging; illustrations and examples are simple and to the point. I was new to patch and this really help me out a lot.
13:05 - It's recommended to use Context Manager for built-in functions
14:00 - Remember that a decorator creates a MagickMock object. It must be passed as an argument into the tested function.
14:39 - Yes, decorators can be stacked. However this is at the expense of DRY.
14:53 - in `setUp`, your patches can be started. You can then stop them all in `addCleanup` if a test goes bad before `tearDown` happens.
A very wonderful clear talk of Lisa 🤩🤩... Haha didn't expect the author would be in the tall😂
Nice talk! There is some an incorrect example at 22:35. It should be self.x = 20 otherwise it's understandable why f.x is not working.
I was just gonna say that.
6:50 - Target must be importable
-- patch auto-imports the target for you
7:30 - Don't patch where the function is declared, but where it is referenced
8:42 - If you import a function from a module: Use the importing module's name to target the function instead of the imported module. This is because the importing module's lookup table contains the function
9:36 - If you import an entire module: Use the imported module's name to target the function instead of the importing function.
Many thanks to Lisa Roach! Very very informative and useful!
haha thank you. You saved me so much time at work.
Extremely clear and concise presentation. Thanks
Great presentation! Patched a lot of holes in my understanding.
Amazing explanation, especially showing what really happens under the hood... Been struggling with finding good documentation on mocking from the past few days and dunno how i missed this
Very good and useful presentation.
Amazing talk, thank you very much for sharing!
This was a huge help. Thank you!
Great explanation for mock n patch. Thanks Lisa!
This is amazing! Thank you!
Perfect explanation. Even layman can understand...
Really nice explained. It's gonna be very helpful to me.
Use property in patch,“new” to mock a case statement flow controlled by a string input? Do they have that in python. Thinking in JavaScript
Kudos to Lisa! PyCon
github link or speakerdeck pycon18 does not show any files for this presentation. can anyone please share the link?
I usually prefer to patch using either a context managers or manual start/stop.
I'm not really a fan of the decorator version, because they add arguments to test classes, which is just really annoying to work with and because they don't allow you to share the mocking config as easily as the context managers and manual start/stop.
Using context manager is also a lot more precise because it makes it really obvious which line of the test function actually requires the patched call. If only one line in the test actually requires patch, then just wrap that line on the context manager, and nothing else.
Manual start/stop is great when you want to totally ignore a dependency. Usually helpful for patching out external calls that is slow or have side effects and failure modes you don't really want to deal with.
This talk is awesome! Thank you!
How do I specify the function that replace the target function?
How did she make patched object db_write return 10 so that her assert(x, 10) works. Didn't see any code for that.
Great one , thanks Lisa!
Nice, but she forgot to name the mocked_thing in the resource manager example. Should be `with patch('module.db_write') as mocked_writer:`
Great talk! Thanks!
God that glove cursor made me anxious
There's one crucial thing missing for me - if I patch it in context manager scope - how can I refer to the mock object? how can I assert how many times was it called? I see mock_* object in two other cases (method and class scope) but I can't see it in CM scope
burbon with mock.patch(‘module.name’) as mock_module:
You can assert on mock_module
@@dustinalandzes thanks :)
Great talk !
Amazing talk! Thank you!
thanks for your good explanation
Excellent talk
super useful; thanks!
thanks for nice explanation:):)
Thanks a lot. REgard from MExico city
If anyone would like to have the slides I have added them here: drive.google.com/file/d/1QvGv8iw5IDHkUNMUXjLDsm-KVsO3Zuhs/view?usp=sharing
Thank you!
Wow! Good talk
Awesome
p