fbpx

Slovník pojmov

V celom blogu používam pojmy, ktoré si možno zaslúžia vysvetlenie. Najmä v prípade, že používam anglický príp. poslovenčený výraz.

TDD, Test-Driven Development

Životný štýl úspešných programátorov ?.

A teraz vážne — je to spôsob vývoja softvéru, kde sa unit testy programujú spolu so žiadanou funkcionalitou. Podstatné je, že najprv vznikne jeden test, čo dokáže odhaliť nedostatok komponentu v nejakej oblasti a až potom upravíme samotný komponent aby tú vlastnosť získal. Pozrite TDD cyklus a zvyšok tohto blogu.

Unit test

Automatický test, ktorý testuje funkcionalitu malého útvaru — väčšinou triedy alebo metódy. Môže to byť aj úzko spolupracujúca skupina objektov, ak tie „pomocné“ nemajú vlastný test. Ale môže to byť aj časť jednej triedy, pričom zvyšok je testovaný iným testom.

Veľmi dôležité je testovať triedu v izolácii — bez toho aby komunikovala s databázou, cudzími API, súborovým systémom, inými triedami, … Dôvodom je:

  • potreba stability. Externé systémy nemusia byť prístupné. Keď zlyhá test, ktorý používa nejaký externý systém, je ťažšie rozlíšiť či je chyba v testovanom kóde alebo sa zmenilo okolie.
  • nezávislosť testov. Test musí byť nezávislý od ostatných a poradia, v ktorom boli vykonané. Ak testujeme komponent s databázou, je ťažšie zariadiť aby každý test po sebe upratal a neovplyvnil nasledujúce testy.
  • rýchlosť. Je bežné spúšťať stovky testov každých pár minút. Pri builde pred komitnutím zmien treba možno vykonať 1000 testov. Ak jeden test trvá dlhšie ako 0.1 sekundy, tak sa to prejaví na zníženej ochote tie testy spúšťať.

Červený test

Test (alebo viaceré testy) objavili problém, ktorý treba opraviť.

Môže to byť chyba, ktorú sme zaviedli pred chvíľou, prípadne si kolega nedal pozor a niečo pokazil a zverejnil.

Alebo je červený test práve napísaný test a produkčný kód sme ešte neriešili. Tento stav je žiadaný pri TDD, lebo je to povinný krok na zabezpečenie dostatočnej kvality našich testov.

Mnohí považujú červený test za hlavný dôvod existencie testov. TDD sa na červené testy pozerá ako na prostriedok ku ich kvalite.

Zelený test

Označuje stav, kedy všetky testy prechádzajú, a tak potvrdzujú, že aplikácia robí to čo má.

Neznamená to, že robí úplne všetko čo má. Týka sa to len existujúcich testov. To znamená, že niečo môže chýbať. Rovnako to nezaručuje bezchybnosť.

V takomto stave môžeme komitnúť naše zmeny do VCS. Ideálne do GIT, kde vieme ešte pred uverejnením spojiť viaceré komity do jedného (squash pri rebase).

Code completion

Moderné editory a IDE ponúkajú možnosť doplňovať text, názvy, znaky, štruktúry a konštrukcie jazyka tak, aby sme nemuseli všetko vypisovať sami. Ja si rád nechám pomôcť. Hlavne keď mám istotu, že mi editor pomáha správne. Šetrí to čas písania a zníži množstvo preklepov v kóde.

Mock, mockovanie

Možnosť izolovať testovanú triedu od okolia počas testu je základný predpoklad na nezávislé testovanie — unit testing.

Izoláciu dosiahneme tak, že inštancie spolupracujúcich tried nahradíme v teste niečím iným, čo predstiera, že je plne funkčná implementácia, ktorú komponent očakáva. V skutočnosti je to podvod zo strany testu, aby dokázal vykonať a overiť svoje experimenty.

Existuje niekoľko druhov zástupných objektov a ja ich v texte jednoducho nazývam mock.

  • stub — objekt, ktorý je naprogramovaný vrátiť vždy tú istú hodnotu alebo sekvenciu hodnôt. Je to dostatočné na to, aby test overil, či testovaná trieda používa správne vrátenú hodnotu.
  • mock — objekt, ktorý sám vyhodnocuje správnosť či absenciu volania. V dnešnej dobe sa používajú takmer výlučne knižnice na dynamicky generované mocky, lebo sú pohodlné a definícia, čo očakávame je čitateľná. Ich nevýhodou je, že sí trošku pomalšie. Príklady: Mockito, EasyMock.
  • spy — zaznamenáva, aké metódy boli zavolané s akými parametrami, prípadne ich poradie. Test si vie podľa týchto záznamov vyhodnotiť, či sa udialo to čo očakával.
  • dummy — potrebujeme do testovanej triedy poslať nejaké údaje, ale testovaná trieda s nimi nič seriózne nerobí, len ich očakáva. Prípadne sa chceme zbaviť volania do externého systému Takže ak tam pošleme čokoľvek, čo spĺňa požiadavky na typ, tak to neovplyvní výsledky. Ako príklad, kde nám nezáleží aké metódy testovaný objekt volá môže byť Logger — málokto píše testy na logovanie.
  • fake — fungujúca implementácia, ale nevhodná do produkcie, lebo nespĺňa všetky požiadavky. Dôvodom môže byť znefunkčnené volanie do cudzieho systému. Lokálna in-memory databáza je tiež dobrý príklad.

Komit, komitnúť, push, pushnúť

Toto snáď netreba nikomu vysvetľovať, ale pre istotu (a tiež aby jazyková polícia prižmúrila jedno oko) to sem napíšem.

Pojem sa týka použitia Version Control System (VCS). Zmeny v kóde zverejníme tak, že ich vložíme do VCS a pošleme na server. Prvá operácia je komit, druhá push. Ktokoľvek v tíme si potom vie prevziať naše zmeny kódu, prípadne pozrieť jednotlivé komity a vizuálne zvýrazniť zmeny, ktoré sme urobili.

Git, VCS

Version Control System (VCS) je softvér, ktorý umožňuje tímom spolupracovať na vývoji kódu tak, aby všetky zmeny boli správne zaznamenané, bolo možné sa v nich orientovať a vracať sa k starším zmenám, ale najmä aby sa nič nestratilo.

Množstvo firiem používa Subvesion (SVN) a donedávna to bol asi najpoužívanejší systém.

Podľa mňa je to najlepší a stále viac a viac používaný Git. Je viac komplikovaný ale „dokáže úplne všetko”. Vážne, kedykoľvek mi napadlo: „To by bolo super, keby som v Gite vedel spraviť toto.” Stačilo sa spýtať Google a prečítať si návod ako sa to robí.

Code coverage

Spustením testu sa vykonáva kód v testovanom komponente. O riadkoch kódu, ktoré sa takto vykonali hovoríme, že sú pokryté testami. A súhrn všetkých riadkov, ktoré boli vykonané všetkými testami je „pokrytie kódu testami”. Zvyčajne sa vyjadruje číslom — celkovým počtom alebo percentom. Viac si môžete prečítať v tomto článku.