Článek
White box testing vs black box testing
Z mého pohledu je black box testing testování, aniž bychom věděli, jak věc funguje vevnitř. Víme pouze, jak se má chovat z pohledu uživatele. Takto fungují klasičtí QA, simulující koncového uživatele. Testují aplikaci tak, jak ji bude používat koncový uživatel. Je to zároveň důvod, proč my programátoři nemůžeme být dobří testeři. Víme prostě, jak věci fungují zevnitř, a proto víme, jak aplikaci testovat, abychom ji „nerozbili“. A proto nám všechny testy prostě projdou.
Naproti tomu existuje whitebox testing, kdy víme, jak to funguje uvnitř, a víme taky, jak to má fungovat. Proto můžeme psát unit testy, které testují, že dostaneme to, co chceme dostat na úrovni kódu. V podstatě to je i rozdíl mezi juniorem a seniorem – pokud má vývojář napsat funkci na zaokrouhlení ceny zboží, jak bude postupovat? Junior napíše funkci, a alespoň v našem webovém světě otevře stránku s formulářem / db, vepíše upravenou hodnotu (cenu) a zobrazí výpis zboží, kde se přesvědčí, že funkce opravdu zaokrouhluje. Senior si napíše tuto funkci, k ní unit testy testující správné zaokrouhlení při různých vstupních hodnotách, a hle – univerzální zaokrouhlovací funkce je na světě.
QA pro vývojáře
Jaké nástroje můžeme jako vývojáři použít, abychom snížili naši chybovost? O unittestech padlo pár slov v odstavci výše, ty testují „chování kódu“. Ale kvalita kódu není jen o jeho funkčnosti, ale také o tom, jak kód vypadá zevnitř. Asi by se nikomu nelíbilo, kdyby letěl v letadle, kde by každý kabel, každá trubka a každý šroub vypadaly divně, ošklivě a tak vůbec. To znamená, že kód který píšeme, musí být hezký.
Co znamená hezký kód? Interně si pravidla dělím na dvě věci, pravopis a stylistiku. Pravopis pohledem vývojáře jsou coding standarts: Mezery tam, kde mají být, správné názvy metod a proměnných (camelCapse vs _poddtrzitkova_anotace) a spousty dalších pravidel, které většině mých mladších kolegů (a kdysi i mně) připadaly jako buzerace. Ke kontrole tohoto typu pravidel slouží různé linty, pro PHP svět zlatý standart – CodeSniffer. No a stylistika? Psát nejenom bez gramatických chyb, ale i správně přehledný kód, rozumně dlouhé funkce, rozumné počty parametrů apod. Pro tohle máme v našem světě nástroj PHPMD (PHP Mess Detector), který umí hlídat dodržování námi napsaných pravidel – třeba metodiky Rozděl a panuj o složitosti/délce jednotlivých metod.
Pořád jsem neřekl, co to přinese nám vývojářům: Kód, který bude vypadat stejně, aniž by záviselo na tom, který vývojář ho psal. Díky tomu, že všichni v týmu budou dodržovat stejná pravidla (v extrému se dá napsat pre-commit hook, který kód s coding standarts violence prostě nevezme), bude jednodušší se v takovém kódu orientovat, bude jednodušší a rychlejší (a tudíž i levnější) v takovém kódu hledat chyby, spoustě chyb charakteru „překlepy v názvech proměnných“ se předejte (unused property apod), a kód bude prostě hezčí, čitelnější, a bude radost s ním pracovat.
No, a protože nás vývoj v AW-devu baví, je jasné, že tyto nástroje máme a používáme.
