You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Začal jsem pracovat na novém zadáním updatem na Django 2.2 (branch django2), což samozřejmě okamžitě způsobilo spoustu problémů. Většinu těch problémů spojených čistě jen s updatem jsem už vyřešil a zbytek nejspíš vyřeším jednoduše pomocí access testů: načtu všechny dostupné (nastavené) url a zkontroluju, jestli mi to vrátí status 200 nebo 404.
Každopádně je možné, že i když se všechny stránky budou načítat správně, tak potom když třeba manuálně použiju nějaký formulář (e.g. vytvoření nového zdroje) nebo podobnou funkcionalitu, tak to buďto crashne nebo to prostě udělá něco trochu jiného než by mělo.
Příklad: stará implementace harvest_urls při /harvests/<datum>/2/urls vrátila všechny sklizně nejen pro 2x ročně, ale také 12x a 52x ročně, protože filter ...__contains vracel všechno, kde se 2 objevila, tedy i 12 a 52, ne jenom přesně 2. Na tohle tam už teď mám test, ale dost možná tam bude podobných problémů více.
Takže co bych vlastně chtěl otestovat: use cases pro hlavní funkce – slovně popsaný postup co vlastně uživatel dělá, když chce provést nějakou akci v aplikaci.
Na příklad "Vytvářím nový zdroj": kliknu 'Add', zadám informace, zadám seedy, ... a na konci vidím, že ten zdroj existuje, má takové seedy, vidím ho já a nikdo jiný, ...
Takže vesměs dokumentace... Dokázal bych si asi většinu akcí odvodit ze samotné práce s aplikací a z kódu, což nejspíš také ze začátku udělám, ale bylo by dobré mít minimálně nějaký seznam těchto use cases, ne nutně profesionální 100-stránkové specifikace.
Důvod: i když budou unit testy na funkcionality samotných modulů (e.g. "všechno" kolem Harvests funguje tak jak má/je v kódu a můžu se spolehnout, že mi to v polovině nějaké akce jen tak nespadne, když tam dám špatné datum), ty samy o sobě nebudou garantovat funkcionality celého systému. Do budoucna by se teda hodilo mít garanci aspoň pro těch několik hlavních funkcí. e.g. #498#478#485#402
Testy:
www: access test všech neparametrizovaných www url (e.g. about)
www: access test všech parametrizovaných www url (e.g. search/)
seeder: access test všech neparametrizovaných seeder url (e.g. seeder/source/list)
seeder: access test všech parametrizovaných seeder url (e.g. seeder/source/detail/)
unit testy pro jednotlivé moduly (e.g. Source, Harvest, ...)
use case testy (integrace několika modulů podle předepsaného postupu)
pozn.: za mě to teď vůbec nespěchá, ale hodilo by se něco takového mít minimálně v dalším zadání, tak na to nechci zapomenout
The text was updated successfully, but these errors were encountered:
To není problém, my už jsme pro sebe interně začali pracovat na vlastní uživatelské dokumentaci, tak ji rozšíříme, tak jak to potřebuješ. Začneme na tom postupně pracovat hned, protože podle mě dává smysl, aby něco takového existovalo.
Začal jsem pracovat na novém zadáním updatem na Django 2.2 (branch
django2
), což samozřejmě okamžitě způsobilo spoustu problémů. Většinu těch problémů spojených čistě jen s updatem jsem už vyřešil a zbytek nejspíš vyřeším jednoduše pomocí access testů: načtu všechny dostupné (nastavené) url a zkontroluju, jestli mi to vrátí status 200 nebo 404.Každopádně je možné, že i když se všechny stránky budou načítat správně, tak potom když třeba manuálně použiju nějaký formulář (e.g. vytvoření nového zdroje) nebo podobnou funkcionalitu, tak to buďto crashne nebo to prostě udělá něco trochu jiného než by mělo.
Příklad: stará implementace harvest_urls při
/harvests/<datum>/2/urls
vrátila všechny sklizně nejen pro 2x ročně, ale také 12x a 52x ročně, protože filter...__contains
vracel všechno, kde se2
objevila, tedy i12
a52
, ne jenom přesně2
. Na tohle tam už teď mám test, ale dost možná tam bude podobných problémů více.Takže co bych vlastně chtěl otestovat: use cases pro hlavní funkce – slovně popsaný postup co vlastně uživatel dělá, když chce provést nějakou akci v aplikaci.
Na příklad "Vytvářím nový zdroj": kliknu 'Add', zadám informace, zadám seedy, ... a na konci vidím, že ten zdroj existuje, má takové seedy, vidím ho já a nikdo jiný, ...
Takže vesměs dokumentace... Dokázal bych si asi většinu akcí odvodit ze samotné práce s aplikací a z kódu, což nejspíš také ze začátku udělám, ale bylo by dobré mít minimálně nějaký seznam těchto use cases, ne nutně profesionální 100-stránkové specifikace.
Důvod: i když budou unit testy na funkcionality samotných modulů (e.g. "všechno" kolem Harvests funguje tak jak má/je v kódu a můžu se spolehnout, že mi to v polovině nějaké akce jen tak nespadne, když tam dám špatné datum), ty samy o sobě nebudou garantovat funkcionality celého systému. Do budoucna by se teda hodilo mít garanci aspoň pro těch několik hlavních funkcí. e.g. #498 #478 #485 #402
Testy:
pozn.: za mě to teď vůbec nespěchá, ale hodilo by se něco takového mít minimálně v dalším zadání, tak na to nechci zapomenout
The text was updated successfully, but these errors were encountered: