BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//talk//93XE3S
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-93XE3S@programme.europython.eu
DTSTART;TZID=CET:20260716T141500
DTEND;TZID=CET:20260716T144500
DESCRIPTION:Has this ever happened to you? You're happily coding a new feat
 ure in your Python project\, and at some point\, you make a hasty call:\n\
 n```\nself._thing.do_someting(rnicro_meters=10)\n```\n\nYou've written uni
 t tests for it\, including an assertion line:\n\n```\nmock_do_someting.ass
 ret_called_once_with(rnicro_meters=10)`\n```\n\nThe tests pass\, the CI is
  green\, the PR is reviewed and merged. But some time later\, the service 
 crashes because the real method does not have the `rnicro_meters` keyword 
 argument in the first place. What happened? And more importantly\, did you
  notice any of the mistakes above? This is a problem we've faced more than
  a few times over the past few years\, and that's a few too many.\n\nUnit 
 tests are crucial in any sort of Python development\, from small libraries
  to large distributed systems. `unittest.mock` is used to isolate dependen
 cies and mock external calls in order to keep the tests simple and focused
 . But mistakes can slip by (e.g.: attribute typos\, wrong keyword argument
 s\, wrong patch locations)\, just like the three mistakes above\, leading 
 to false positive tests and a false sense of confidence in our code qualit
 y. This can happen because `Mock` and `MagicMock` silently auto-creates at
 tributes on the fly\, even when those attributes do not exist on the real 
 object. These issues become even more pronounced as dependencies change an
 d projects evolve.\n\nIn this session\, we’ll look at why these false po
 sitives happen\, and how to avoid them. Topics include:\n\n- Understand ho
 w `Mock` and `MagicMock` allow invalid attributes and calls.\n- Common pit
 falls and anti-patterns with `Mock`\, `MagicMock`\, and `patch`.\n- Using 
 `spec`\, `spec_set`\, and `autospec` to force mocks to match real objects.
 \n- Ensuring patched functions and methods have their signatures validated
 .\n- How to avoid patching the wrong import path.\n- Introducing guardrail
 s in existing projects (e.g. OpenStack’s approach) without rewriting the
  entire test suite.
DTSTAMP:20260524T130832Z
LOCATION:Chamber Hall B (S3B)
SUMMARY:What is this footgun called unittest.mock\, and how to avoid misusi
 ng it - Claudiu Belu
URL:https://programme.europython.eu/europython-2026/talk/93XE3S/
END:VEVENT
END:VCALENDAR