Tohle je trošku fishy, protože by se to teoreticky mělo dít i u
produkce, leč tam zůstávají práva persistentně v DB (a až se rozbijí,
tak se budeme divit)…
Není úplně žádoucí, aby se v mailu z testwebu poslala spousta adres,
protože je to náchylné na automatické zpracování v případě, že se k
takovému mailu dostane někdo další.
Ten řádek má sice pořád 117 znaků, ale IMHO je to o dost lepší.
Mně to i správně vyplňuje subjecty v Thunderbirdu, takže můj kód asi
není úplně mimo :-)
Označení bylo zavádějící, protože se vůbec nejedná o objekt Hodnocení.
Neříkám, že nové jméno je nějak úchvatné, ale aspoň mě nemate a na
proměnnou s životností dva řádky je to stejně jedno…
Vyrábí odkazy, které vedou na poslání mailu.
Psal jsem to spíš po paměti, nejsem si jistý, že to takhle je přesně
podle příslušného RFC, ale jako PoC dobrý a když to nebude fungovat, tak
se implementace opraví.
Všimněte si, že to je otestované, takže když někdo opraví testy
(=předpis chování), tak je pak snadné z diffu a všeho odvodit úpravu.
V Django dokumentaci se píše něco o tom, že by se měl použít spíš
`format_html` a `conditional_escape`, ale zatím jsem to víc nezkoumal.
Je žádoucí z tagu {% maillink %} odddělit i tag {% mailurl %}, který by
vracel samotnou URL. Obojí dává smysl umět (speciálně bastlení odkazů z
URL je stejně strašně nepřehledné, takže je lepší to zavřít do {%
maillink %} a nikdy nevidět), ale zatím to oddělené není… (Ale jsou na
to testy, takže by se mělo aspoň dát poznat, že rozdělení nerozbije
chování.)
Při běžení testů nejdéle trvá namigrovat (prázdnou) databázi. Toto tento
krok přeskočí.
By default django pro testy používá in-memory SQLite3 databázi, která se
schovat přirozeně nedá. Používání souborů trvá déle (data níž), ale
další běhy už jsou rychlé.
Zatím nevím, jestli se někde nemůže omylem schovávat nějaký nežádoucí
stav, ale testy mi i opakovaně běží, takže se to asi nerozbíjí úplně
moc. Na první pohled je uložená databáze prázdná.
Pro produkci a CI bych klidně běžel testy od nuly, tam nevadí čekat pár
desítek sekund až jednotky minut na výsledek. Tato optimalizace je
důležitá jen pro lokální vývoj, kde je žádoucí mít testy co
nejrychlejší.
V .gitignore už přesně toto jméno souboru je. Nevím proč, ale možná to
tak bylo by default v některém dávném Djangu.
Data
---
Spouštěl jsem příkaz `time ./manage.py test [--keepdb] api`. Běhy byly
relativně konzistentní (±1 s) a trvaly u mě:
- In memory SQLite (default): 26 s
- První spuštění s db na disku (HDD): 44 s
- Následná spuštění: 7.7 s
Data jsou nejspíš zkreslena tím, že všechno je nejspíš nacachované v
systému, ale i tak je vidět zřetelné zrychlení.
Původní motivace: úplně triviální a nedatabázový test na starém
notebooku běžel kolem 3:14, což je zoufale nepoužitelné když si chci
napsat testy jako pomůcku pro vývoj.
