BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//speaker//CNF9B
 G
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-LNVDY3@programme.europython.eu
DTSTART;TZID=CET:20260715T125000
DTEND;TZID=CET:20260715T135000
DESCRIPTION:Most Django testing tutorials stop at "write a test\, make it p
 ass\, refactor." But real-world Django applications have complex model rel
 ationships\, permission systems\, third-party API integrations\, and async
 hronous task chains that demand more sophisticated testing strategies. Aft
 er delivering a hands-on TDD workshop at DjangoCon US 2023 and applying th
 ese patterns across multiple production Django codebases\, I've identified
  a set of recurring testing patterns and anti-patterns that significantly 
 impact both test reliability and developer productivity.\n\nThis poster pr
 esents a visual field guide to practical TDD patterns in Django\, organize
 d as a decision-tree poster that developers can reference when writing tes
 ts for their own projects.\n\n**Section 1 — The Factory Pattern Taxonomy
 .** A visual decision tree for choosing the right `factory_boy` strategy b
 ased on your model structure. When to use `SubFactory` vs. `RelatedFactory
 ` vs. `LazyAttribute` for foreign keys\, how to handle circular relationsh
 ips without creating test data explosions\, and the `create` vs. `build` v
 s. `build_batch` decision that controls whether you hit the database. Anno
 tated with `faker` provider selection for generating realistic test data t
 hat keeps test failure messages readable.\n\n**Section 2 — Testing Permi
 ssion Layers Without Drowning in Fixtures.** Django apps often have three 
 or more permission layers: model-level\, view-level\, and object-level (vi
 a packages like `django-guardian` or row-level security). This section sho
 ws a visual matrix for structuring permission tests: one axis for user rol
 es\, one for resources\, and a clear pattern for generating all combinatio
 ns using parameterized tests with `pytest.mark.parametrize` and factory tr
 aits. Instead of writing 30 separate test functions\, you write one parame
 terized test with a role-resource matrix.\n\n**Section 3 — The Mock Boun
 dary Diagram.** A flowchart showing where to place mocking boundaries in a
  Django request lifecycle. The poster illustrates the difference between m
 ocking at the view level\, the service layer\, and the adapter/client leve
 l — and why mocking too deep creates brittle tests while mocking too sha
 llow creates slow ones. Includes a decision rule: "Mock at the boundary wh
 ere your code meets code you don't own."\n\n**Section 4 — Common Anti-Pa
 tterns and Fixes.** A visual rogues' gallery of the five most common Djang
 o testing anti-patterns with before/after code comparisons: test database 
 leaks from missing `TransactionTestCase`\, over-mocking that tests impleme
 ntation instead of behavior\, fixture files that nobody can maintain\, tes
 t ordering dependencies\, and the "God factory" that creates half the data
 base for every test.\n\nVisitors will gain a practical decision framework 
 for structuring Django tests\, rather than just knowledge of individual te
 sting tools. The patterns are tool-agnostic at their core (though examples
  use `pytest-django`\, `factory_boy`\, and `faker`) and apply to any Djang
 o project.
DTSTAMP:20260524T122013Z
LOCATION:Poster Hall B
SUMMARY:Django TDD Patterns: A Visual Field Guide - Kuldeep Pisda
URL:https://programme.europython.eu/europython-2026/talk/LNVDY3/
END:VEVENT
END:VCALENDAR