Jak píšete testy a k jakému účelu? rubrika: Folklór

12 Kit
položil/-a 17.5.2015

Navazuji na téma http://devel.cz/otazka/ako-rychlo-zistit-kvalitu-firmy-alebo-vyvojoveho-...

Když pročítám debaty o TDD, tak z toho mívám pocit, že vývojáři považují psaní testů za nutné zlo. Z toho mi vyplývá otázka: Píší ty testy správně? Vždyť účelem testů není házet vývojáři klacky pod nohy a zdržovat ho, ale usnadnit a zrychlit vývoj. Také udělat z vývoje aplikace zábavnou hru - je to jako hrát šachy sám se sebou. Chvíli píši test, chvíli jednotku - jako když otáčím šachovnici. Když je partie dohrána, jednotka je hotova.

Jak jste na tom s psaním testů? Je to pro vás otročina nebo zábava?

Komentáře

  • Honza Břešťan : Mne se hrozne libi, jak si umis v otazce rovnou odpovedet a zaroven predem zautocit na jine mozne odpovedi :) 17.5.2015
  • dzejkob : Já jsem z jinýho světa. Pro testování používám vynález principiálně podobný code contracts a celý vývoj je nějaký střet s neustále se upřesňující a měnící specifikací. Věci, který jsou si fakt už jistý svojí existencí se opíšou nějakým integračním testem nebo scénářem v seleniu. TDD jsem letmo zkoušel - kdybych na to najel, musel bych okamžitě podat výpověď, protože specifikaci v té kvalitě, která je pro to potřeba, mi nikdo dodat nedokáže. To neřikám, že to dobře ovládám, mám to napsaný v deníčku jako to-practise - ale asi spíš na jiném projektu. 17.5.2015
  • Taco : @dzejkob: Toto mě zajímá. Mohl by jsi prosím uvést více informací k té první větě (selenium a integračí testy mě až tolik nezajímají - spíše to "code contracts")? Frameworky, jazyky? 17.5.2015
  • dzejkob : Já to myslel tak, že kontroly předpokladů provádím různě v kódu - takže dost věcí je reálně zbytečnejch - ale jsou tam, aby byla jistota, že to funguje. Typicky třeba tento seznam musí být setříděný, když nastal nějaký konkrétní stav, tak to je chyba, kontroly konzistencí, kontroly vstupů, integritní omezení aj. Možná bych to měl spíše správně nazvat jako unit testy vepsaný přímo do kódu. Proč mockovat, když to uživatelé mocknou za mě :) Voni jsou s tím smíření - a že vobčas holt odkliknou messagebox nevadí - neboť plnohodnotný CI je poněkud dražší. Vývoj je rychlej, flexibilní to je a všichni jsou spokojení. 17.5.2015
  • vaclav.sir : Tohle nemá s unit testy nic společného, při těch se testuje izolovaná jednotka v prostředí uvedeném do známého stavu. Možná bys to měl spíše správně nazvat jako runtime checking. 18.5.2015
  • lad.slezak : @dzejkob: Hm, to je spíš validace vstupů. Tím jen kontroluješ vstup, to nic neříká o tom, že výstup je správný. A to právě unit test kontroluje, že pro daný vstup obdržím určitý výstup. 22.5.2015
  • dzejkob : Jakémukoliv "výstup je správný" musí předcházet alespoň trochu jasná specifikace, co to ten výstup je. Kontroluju taktéž předpoklady a výstupy soustavy komponent, bohužel mnohdy i zpětně. Co se týče kontroly vstupů, tak pokud do některé komponenty díky předchozím komponentám doteče špatný vstup a ona to zachytí, tak je to důkaz, že předchozí komponenty udělaly něco blbě. Není to samozřejmě na 100% ale riziko to snižuje taktéž. 22.5.2015
  • v6ak : @dzejkob: Aby z toho byly unit testy, bylo by potřeba aspoň přidat nějakou sadu vstupů, na které by se to vyzkoušelo, třeba i trochu náhodně. (I když náhodnost u testování je trochu problematická a minimálně nějaké charakteristické testy je vhodné mít explicitně.) Pak po úpravě třeba i nějakého knihovního kódu můžeš ho jednoduše otestovat tou sadou vstupů. Budou to testy trochu ve stylu QuickChecku, což ale není nutně špatně. 22.5.2015
  • dzejkob : Jo - do kritickejch věcí jsem sypal třeba hodinu náhodný vstupy - našlo to fakt zajímavý souvislosti a chyby, který by mě nikdy nenapadly. 22.5.2015
odkaz
8 JaSei
odpověděl/-a 20.5.2015

Pro me jsou testy radost, zejmena kdyz refaktoruju, tak je to super pocit, nebat se do toho hrabnout... A naopak nadavam na neotestovany kod, protoze do toho hrabat je vzdycky pruda a musi se k tomu predtim ty testy dopsat a dopisovat testy k hotovemu (a jeste navic cizimu a/nebo staremu kodu) je pruda...
Nicmene psani testu je o tom to umet a je treba refaktorovat i testy a ucit se lepe psat testy...

Komentáře

  • Taco : Existuje užitečné pravidlo: Refaktorovat kód, nebo testy - nikdy najednout. 20.5.2015
  • chikeet : @Taco: A co případy, kdy se mění rozhraní testovaného kódu? Nebo to už přesahuje pojem refaktoring? 22.5.2015
  • Kit : @chikeet: Při změně rozhraní opravíš test. 22.5.2015
  • Taco : @chikeet: Ano, pak se tomu obvykle říká redesign (kódu). 22.5.2015
  • vaclav.sir : Když měníš rozhranní kódu, tak refaktoruješ kód. Zároveň přitom pochopitelně opravuješ i testy, ale neděláš jejich refaktoring. 22.5.2015
  • Kit : @vaclav.sir: To se právě nedělá zároveň. Když měním rozhraní kódu, opravím testy. Teprve když neprojdou, opravuji kód. Není to refaktoring, ale (jak uvedl @Taco) redesign. 22.5.2015
  • JaSei : rekl bych ze kdyz menis rozhrani, tak nejdriv upravis testy a pak proti tomu prepisujes kod (pokud jedes TDD, coz se mi ne vzdycky dari, ale snazim se a je to fajn, kdyz se povede) 23.5.2015

Pro zobrazení všech 14 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.