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.
Uvědomil jsem si, že aktuálně nejde skoro vůbec poznat, jestli make
skript uspěl nebo ne. Tohle by se mělo vypsat, když se nepovede.
Víc by se mi líbilo, kdyby úspěšné doběhnutí ohlásilo "OK", ale to
neumím udělat bez nějakého zápatí skriptů.
(Resp. uměl bych: make/lib může být interpretr, který na začátku
zinicalizuje proměnné, pak natáhne příslušný skript a na konci ohlásí
OK. Ale přijde mi to trochu moc magické, takže pokud někdo nebude nějak
extra pro, tak to tak neudělám :-))
Ne že by mi na tom záviselo, ale kód to nezhoršuje a pokud to aspoň o
trochu zmenší šanci na nějaké přehlédnutí, tak je to OK.
A spoustu varování shellchecku jsem vyignoroval a nemíním plevelit kód
komentáři, o čem všem vím a on ne :-)
Všechny make skripty stejně vyrábí venv přes `ensure_venv` a protože web
nikdo nikdy nebude instalovat jinak (nebo když bude, tak asi ví, co
dělá), tak tohle nedává smysl spouštět.
- Přidal jsem `set -euxo pipefail`, takže nejsou potřeba `&&` a obecně se
to chová víc jako ostatní make skripty
- Venv se zapíná stejně jako v lokálních skriptech, takže se dá
jednoduše změnit jeho cesta
Pavel "LEdoian" Turinsky
Jonas Havelka