Monday 4:30 p.m.–5 p.m.
To mock, or not to mock, that is the question
- Audience level:
Mocking is a very powerful testing concept that has some dangerous pitfalls. There are obvious use cases where mocks are an absolute requirement to be able to test a part of the app. Nevertheless sometimes apparently useful mocks can yield erroneous test results. This talk goes into deeper detail on the trade-off of using mocks in testing.
Quality of unit tests is as important as the presence of tests themselves. If you do write unit tests for your projects, then you probably came across the necessity to mock or stub some of the "units" of the system. Roughly there are 2 extreme schools of thought on this matter: "never mock" and "mock all the things". The goal of this talk is to find the middle ground between these two and present the strengths and weaknesses of each. We will examine common cases of "good mocks" and how these help tests to pass and stay logically correct. Conversely [mock](https://mock.readthedocs.org/en/latest/) library in Python 2 or, for the lucky one who switched to Python 3, [unittest.mock](https://docs.python.org/3/library/unittest.mock.html) module included in STL, can induce major flaws into the testbase. Tests should be simple and error-proof, otherwise the whole point of tests is lost, right? With mocks it becomes even easier to let those logic pitfalls creep in and ruin some assertions. Additionally we will look into some examples of testing slightly more complex systems like a Django app, where there's always need to alleviate between functional and unit tests, and how mocks can save or ruin the day.