Skip to content

test(cache): pozorne testy cache na realnym backendzie zamiast DummyCache (3.2) - #648

Merged
mpasternak merged 2 commits into
devfrom
fix/cache-tests-real-backend
Jul 24, 2026
Merged

test(cache): pozorne testy cache na realnym backendzie zamiast DummyCache (3.2)#648
mpasternak merged 2 commits into
devfrom
fix/cache-tests-real-backend

Conversation

@mpasternak

Copy link
Copy Markdown
Member

Problem

Cała warstwa cache jest w testach wyłączona (CACHEOPS_ENABLED=False +
DummyCache). Testy, które twierdziły, że sprawdzają cache, przechodziły
z niewłaściwego powodu — zielony, który niczego nie dowodził (poz. 3.2 audytu).

Zmiana (test-only)

Testy sprawdzające zachowanie cache przełączone na realny LocMemCache
przez jawny, lokalny fixture (wzorzec test_cache_publiczny.py) — bez zmiany
globalnych ustawień testów:

  • test_robots_txt_sitemap_zalezna_od_hosta (separacja host) — na LocMem
    z asercją kontrolną,
  • test_zapis_uczelni_inwaliduje_cache_strony_glownej — odmockowany
    (był tautologią na cache.delete), teraz dowodzi realnej inwalidacji.

Wynik

Inwalidacja Django-cache DZIAŁA naprawdę — potwierdzone sabotażem (wyłączenie
cache.delete w sygnale → test pada). 0 realnych bugów — separacja hostów
po build_absolute_uri nie przecieka. Warstwa cacheops pozostaje testowana przez
spy na .invalidate() (globalnie wyłączona w testach; włączanie per-test
niebezpieczne pod xdist — monkey-patch ORM + cross-worker leak w Redisie).

Review: PASS + APPROVED (brak wycieku fixture — 70 passed razem z sąsiednimi plikami).

Poz. 3.2 audytu.

🤖 Generated with Claude Code

https://claude.ai/code/session_019GmViAsaif9MXeuDMA5NHX

mpasternak and others added 2 commits July 20, 2026 21:34
…dzie

`test_robots_txt_sitemap_zalezna_od_hosta` biegł na DummyCache (cache
wyłączony w testach), więc `cache_page` niczego nie zapisywał — test
host-separacji przechodził trywialnie i nie dowodził, że cache NIE
przecieka między domenami multi-hosted.

Podmiana backendu na LocMemCache (wzorzec z test_cache_publiczny.py i
admin_dashboard/test_cache_vary_host.py) + warunek kontrolny (powtórzone
żądanie na ten sam host MUSI trafić w cache). Zweryfikowano sabotażem:
z DummyCache asercja kontrolna pada (3 != 2 renderowania), z LocMem
przechodzi. Realny cache nie ujawnił buga — cache_page poprawnie kluczuje
po hoście (build_absolute_uri).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019GmViAsaif9MXeuDMA5NHX
…wanie)

`test_zapis_uczelni_inwaliduje_cache_strony_glownej` mockował `cache.delete`
i `get_uczelnia_context_data.invalidate` — tautologia: dowodził, że sygnał
WOŁA delete(klucz), a nie że context-procesor `uczelnia` czyta ten sam klucz
ani że po zapisie serwuje świeżą wartość.

Przełączony na realny LocMemCache (wzorzec test_cache_publiczny.py) z pełną
ścieżką zapis→odczyt→inwalidacja context-procesora (klucz bpp_uczelnia_<pk>).
Dodany warunek kontrolny (rule #8): zmiana przez .update() (pomija post_save)
zostawia STARĄ wartość w cache — dowód, że cache realnie trzyma migawkę.

Zakres: cacheops jest w testach globalnie wyłączony (INSTALLED_APPS bez
cacheops + CACHEOPS_ENABLED=False, monkey-patch/xdist landmine), więc warstwa
`@cached` pilnowana osobno przez spy; realnie testowana warstwa Django-cache.

Zweryfikowano sabotażem: z wyłączonym cache.delete w sygnale test pada w p.3
(stary wpis przeżywa). Inwalidacja DZIAŁA naprawdę — bug NIE ujawniony.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019GmViAsaif9MXeuDMA5NHX
@mpasternak
mpasternak merged commit 5733fba into dev Jul 24, 2026
22 checks passed
@mpasternak
mpasternak deleted the fix/cache-tests-real-backend branch July 24, 2026 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant