Přejít k navigační liště

Zdroják » Různé » Začít testovat je jednoduché

Začít testovat je jednoduché

Články Různé

Kolikrát jste přemýšleli, že začnete testovat? Že „ty testy“ použijete alespoň na nejdůležitější třídy, popřípadě na opakující se chyby? Čas běží a testy pořád nikde! Navíc nadřízení se ptají, zda to nezabere zbytečně čas, který by mohli nafakturovat zákazníkovi. Nebo si snad myslíte, že umíte psát software bez chyb?

V prvním ze série článků se podíváme na dva největší vývojářsko-testovací mýty a vyvrátíme je:

  1. testování zabere příliš mnoho času,
  2. jsem neomylný vývojář a chyby nedělám.

Vývoj bez testů

Už jste někdy napsali v PHP následující kód (nebo velmi podobnou obdobu)?

$obj = new MojeTrida;
$result = $obj->nejakaMetoda($nejakyParametr);
var_dump($result);

Takhle se totiž vyvíjí v PHP nejčastěji. Napíše se třída, zavolá se metoda a pohledem zjistíme, zda to dělá, co to dělat má. Takový kód napíše programátor mnohokrát denně – ostatně na tom není nic špatného. To špatné je, že kód potom smažeme a důvěřivě očekáváme, že se třída nerozbije.

Jenže ona se rozbije! A my, protože jsme si testovací výpis smazali, se o tom dozvíme buďto pozdě (třeba až po nasazení na server), nebo sice brzo, ale kolikrát nám zabere spoustu času zjistit, kde chyba je. Proč? Protože se může projevit v úplně jiné třídě – jen proto, že „side effect“, který má třída způsobit, se za určitých podmínek, nevykoná.

Trvalé testy

Podívejme se na jiný způsob, jak tento výpis použít a přitom si test nechat:

// ... hlavička testu (povíme si později)
$obj = new MojeTrida;
$result = $obj->nejakaMetoda($nejakyParametr);
var_dump($result); // toto až nebudeme potřebovat, tak to zakomentujeme
$this->assertEquals(array(1, 2, 3), $result);
-- ... patička testu (také si povíme později)

Jak vidíte, kód, který jsme napsali, je téměř identický. Samotná třída testu je opakující se šablona, takže její napsání nám nezabere žádný čas navíc (každý slušný editor i IDE umožňuje uložit si šablony kódu). Takto to u testů vždy není, ale mnohdy je vytvoření testu skoro tak jednoduché, jako vytvoření výpisu výsledku.

PHPUnit

Jak vypadá naše šablona v PHPUnitu:

class NazevTridyTest extends PHPUnit_Framework_TestCase
{
    public function testNejakaMetoda()
    {
        // .. zde prijde váš kód
    }
}

Kód spustíme příkazem: phpunit NazevTridyTest.php (test musí být uložen v tomto souboru – je navíc danou konvencí, že názvy souborů testů končí na Test.php) nebo phpunit nazevSlozkySTesty. (Postup instalace PHPUnitu najdete na webu tohoto nástroje.)

Samozřejmě PHPUnit umožňuje mnohem víc, o tom si v příštích dílech napíšeme víc.

Programátoři chybují

Mýtem druhým je, že programátoři nedělají chyby. Toto je skutečně mýtus – a to doslova ohromný! Proč tedy neustále vycházejí minor updaty veškerého softwaru? Tím myslím nejen PHP knihovny, tak i operační systém, databáze, překladače C atd.? Jednoduše proto, že chyb je všude spousta. Podívejte se na libovolný changelog libovolného projektu, najdete tam u minor updatů (a často i u větších verzí) více oprav chyb, než nových vlastností. Zhoubnost tohoto jevu je jasná: méně chyb znamená více vlastností, popřípadě lepší uživatelské rozhraní, dokumentace.

Často slýchávám od programátorů v Javě a dalších staticky typovaných jazycích, že je chrání typové kontroly a že testy nepotřebují. Proč potom pochází většina testovacích knihoven z Javy? Proč největší advokáti testování píší v Javě? A jsou to programátoři s praxí v řádu desítek let, ti testy určitě nepotřebují kvůli nedostatku kompetence.

V zásadě lze ověřit, zda kód funguje, pouze čtyřmi způsoby. Formálním ověřením (pomalé, mnohdy takřka nemožné – žádný zaměstnavatel to nezaplatí, pokud nevyvíjí zrovna ovladače pro umělá srdce apod.), metodou Design by contract (která je sice solidní, nicméně bez podpory přímo v jazyku nepohodlná), automatizovanými testy a nebo neustále klikající stovkou pákistánských testerů (drahé – a to i když najmete ty nejhorší Pákistánce vůbec). Bez testu jednou z těchto metod nelze říct, že kód funguje.

Jeden programátor nikdy v hlavě velký systém do důsledků nepojme – a už vůbec ne, když přijde požadavek na hotfix a na záda mu dýchá nadřízený, jehož asistentka kvůli chybě nemůže pracovat, a vy slyšíte: „Ale vždyť přeci stačí taková maličkost – tady to výsledné HTML jen přepsat regulárním výrazem?!“.

Vývojáři jsou často nuceni do kompromisů. Obvykle na ně přistoupí s podmínkou, že „až bude čas, tak se to přepíše“. Je to taková forma upokojení sama sebe, nicméně to právě zanáší do systému chyby, nejednoznačnosti, nelogické a nekoncepční prvky.

V dalších dílech tohoto článku se dozvíte, jak testovat snadno, nestrávit tím příliš času a přitom jen získávat. Pokročilejší techniky, které se v manuálu nedozvíte, se můžete naučit na školení testování, které pořádá Internet Info spolu s autorem článku Jiřím Kneslem.

Komentáře

Subscribe
Upozornit na
guest
18 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Borek Bernard

Ahoj Jirko, tvůj článek je v krátké době už druhý pokus o úvod do testování zde na Zdrojáku, a jelikož má v mnoha ohledech podobný tón jako článek předchozí, na některé věci bych rád zareagoval. Měj prosím na paměti, že jsem člověk, který má testování moc rád a ve své praxi ho aktivně používá, takže moje kritika rozhodně nemíří proti testování jako takovému, jen proti použitým argumentům, nebo dle mého názor spíš „neargumentům“.
Právě určitá iracionalita mi asi vadí nejvíc. Například se většinou a priori předpokládá, že automatizované testování je levnější než manuální. Lze to říct paušálně? Máš odkaz na zdroje, které by to potvrzovaly? V dolarech, ne v nějakých jednotkách typu počet defektů / LoC? Pochopitelně, když uvedeš triviální příklad metody, která něco vrací a dá se proti ní snadno napsat assert, vypadá testování jako prakticky zadarmo, ale ne každá metoda vrací výsledek; ne každá metoda je napsaná slušně; ne každý jazyk je dynamický; ne pro každý jazyk existují pohodlné nástroje atd. atd. Testování často není procházka růžovým sadem a čtenáři by to měli vědět.
Pár dalších připomínek:
* To, že testování zabere hodně času, není mýtus, ale často fakt (minimálně v některých typech aplikací – kontext je vždy důležitý). Testování je investice, ne oběd zdarma.
* Obtížnost testování není v přidání hlavičky třídy a spuštěním unit testů z příkazové řádky, ale ve vytvoření kvalitní testovací suity. To může být podobně těžké nebo i těžší, než vytvoření produkčního kódu.
* DBC neověřuje, jestli kód funguje (jeho úloha je související, ale trochu jiná)
* V metodách ověřování funkčnosti zcela chybí reálné používání aplikace. Proč? Je to zdaleka nejrozšířenější metoda (každý kód se ve výsledku používá a tedy i testuje) a dovolil bych si dokonce tvrdit, že je tato „metoda“ při správném využití velmi nákladově efektivní.
Jsem rád, že se o testování píše, ale trochu realističtější a upřímnější pohled by článkům určitě neuškodil :)
B.

Jiří Knesl

Ahoj Borku,
pokládáš otázky, které samozřejmě jsou k tématu, nicméně z pohledu člověka, který už testy nějakou dobu píše. Já, pokud chci otestovat věci, které jsou opravdu složitější (zvlášť pokud metoda žádá složitě strukturované parametry, ale i v jiných případech), taky se nevyhnu vyšší časové náročnosti.
Nicméně pro začátek testování ti opravdu stačí ty asserty na return (a třeba na to, že „to vytvořilo soubor/zavolalo třídu, která vytvoří soubor“. Začátek testování není opravdu o nic složitější, než print_r.
Aby se testy psaly tak, jak se psát mají, to je náročnější jak na kompetence programátora, tak i na čas… tento díl rozhodně není poslední a do složitějších témat se lidi dostanou, uvědomí si, co něco stojí a co zůstává dál zadarmo.
Nicméně věci jako testování seleniem jsou „skoro“ zadarmo… v podstatě to nakliká i méně zkušený uživatel, programátor to pak jen opraví z XPath na CSS selectory a hurá, máme akceptační test.
Ve výsledku si myslím, že se to vyplatí, zejména pokud testy vznikají před kódem – programátor VÍ, co to má dělat, v případě BDD i ví, jaký to má mít přínos a tím zaručuje nějakou kvalitu pro své nadřízené i klienta. To jsou peníze, které se ušetří už díky kvalitnímu navržení user stories, třeba i díky prototypu. Testování (a už vůbec ne TDD) nejde nikdy samo bez dalších agilních technik/metodik, takže si myslím, že je velmi složité vůbec měřit „co se ušetřilo čím“. Vím jen, že určitá kompozice agilních technik a metodik vede k lepšímu software v kratším čase (ano, například „se dodržují časové rozvrhy“, což pro mě v době waterfallu, nedejbože cowboy codingu bylo nemožné).
Ad DbC (eiffel.com):
„To programmers and the projects they work on, this guarantees that bugs will be prevented by a well defined mechanism based on checks and balances. For managers, DbC ensures that programming is done correctly. For customers, it offers a label of quality, seriousness, and a job well done.“
Tak mi řekni, v čem je cíl (ne použité prostředky) jiný, než kombinace unit a akceptačního testování?
Borku, v dalších dílech se účastníci dozví právě tu „vyšší dívčí“ a největší žrouty času. PHPUnit obsahuje spoustu nástrojů, které se snaží šetřit čas, jakkoliv uznávám, že třeba fixtures bych řešil úplně jinak, ikdyž jsou poměrně snadné. Ale tak to už jsou opravdu věci do dalších dílů.
Nicméně je pravda, že ty nejvíc „vydřené“ zkušenosti stejně řeknu jen lidem na školení, protože jinak by jim přeci stačilo přečíst si pár článků… :)

Borek Bernard

Zeptám se znovu – máš nějaká data, která by tvůj subjektivní pocit potvrzovala? Protože přímo nebo nepřímo tvrdíš, že např. napsáním o hodně víc kódu (kód plus testy) nedojde k natažení projektu, ale někdy i k jeho zkrácení. To je velmi silné tvrzení, které stojí minimálně za vysvětlení, lépe za podpoření nějakými daty.
Ad DBC – nevím, jak v jiných jazycích, ale v .NETu mají kontrakty podobný smysl jako např. určení typu proměnné, tj. přidáváš do produkčního kódu nějaká metadata o tom, jak by se program měl chovat, a nástroje buď v době kompilace nebo za běhu tato omezení hlídají. Pokud kompilaci považuješ za techniku testování, pak asi můžeš i DBC, ale tento pohled mi není blízký. Pochopitelně, obě věci přispívají ke kvalitě kódu, takže mají jeden velký společný cíl, jako ostatně většina věcí, co při programování děláme.

Jiří Knesl

Borku, jenže já tvrdím, že není možné vytrhnout jen „nákladovou strukturu“ psaní testů, protože to ovlivňuje až příliš moc věcí. Bylo by možné porovnávat pouze „firmy dělající vodopád a netestující“ s „firmami dělajícími agilní metodiky a techniky včetně testování“ – to proto, že testování jde často ruku v ruce s řadou dalších.
To je jako bys měl vážit, zda je člověk produktivnější s nebo bez verzovacího systému. Já tvrdím že s, ale opět – mám to nějak zapojené do svého workflow, verzování používat umím, takže mi to čas moc nebere, někdo jiný by zase „bádáním nad tím, jak často komitovat“ strávil čas, který by jinak trávil vývojem.
Omlouvám se, ale přesná čísla prostě nemám. Jen vím, že důvod č.1, kvůli kterému si mě většina firem najímá na školení je to, že se potýkají se spoustou chyb a testování právě chtějí nasadit pro řešení těchto problémů. Jenže se na to pojí i naučení se tuny dalších věcí, jako jsou návrhové vzory, vůbec objektové přemýšlení, dependency injection atd.
Co se DBC týká, tam prostě vycházím z Eiffelu, protože ti ho vymysleli a zahrnuli přímo do jazyka, ergo předpokládám, že popis na webu Eiffelu bude nejblíž skutečnému: „jak jsme to zamýšleli a jak to opravdu má fungovat“.

Borek Bernard

>>> Jenže se na to pojí i naučení se tuny dalších věcí, jako jsou návrhové vzory, vůbec objektové přemýšlení, dependency injection atd.
Přesně! Testování a související věci jsou rozsáhlá oblast vyžadující daleko víc než „public class MyTests“ – ty to určitě víš, ale z článku to jaksi není cítit.
Mimochodem, v článku píšeš čtyři způsoby, jak kód odestovat (ačkoliv DBC za techniku testování nepokládám, ale budiž), aniž bys zmínil páty, zdaleka nejčastější způsob – reálné používání aplikace v provozu. Není to sice způsob moc rigorózní a někdo by ho možná ani za techniku neoznačil, nicméně faktem je, že uživatelé aplikaci používáním vlastně testují. Například takové beta testování může být někdy daleko efektivnější než snaha psát rigorózní testy – minimálně za zmínku to stojí.

Jiří Knesl

Borku, nalezení a odstranění chyby v provozu, to je způsob testování, který bych nerad komukoliv doporučil. Je to z mnoha důvodů ekonomicky velmi nevýhodné. Ano, klient vždy nakonec nějaké chyby najde. Ale čím více z nich se dá najít dřív, tím líp.
Navíc tato série bude více o testování kódu, než o testování „funkčnosti a splnění specifikace“, což bývá právě spíše doména akceptačních testů.

Borek Bernard

Pobaveně sleduju, že ačkoliv k vývoji asi oba přistupujeme dost podobně (unit testy, možná i TDD, důraz na kvalitu apod.), hodně se lišíme v „názorové flexibilitě“. Testování je z mého pohledu příliš neexaktní oblast na to, abych si dovolil pronášet absolutní výroky jako „testování za provozu je ekonomicky velmi nevýhodné“, „čím víc chyb nalezených dřív, tím líp“ – u vývoje je vše o kontextu a v řadě případů nebudeš mít s těmito výroky pravdu. Ale koneckonců, pevné přesvědčení se u propagátora cení, takže OK :)

Jiří Knesl

Docela dlouho už nám to utíká pryč od PHPUnitu, ale proč ne. :) Samozřejmě každá fáze projektu má svoje, některé části jsou skvělé, když se řeší Unit Testy, jindy dojde na akceptační testování, BDD, klient na pracovišti. Nicméně si myslím (a mám za to, že by se se mnou asi dost lidí shodlo), po odevzdání iterace by měl být kód opravdu maximálně funkční, neboť se začne používat v ostrém provozu, sedí tam pracovníci a pracovnice zákazníka, které dostávají určitovou hodinovku a je na nich závislý třeba koncový zákazník. Jakékoliv prostoje v produkčním kódu můžou znamenat opravdu obrovské finanční ztráty, které můžou mnohonásobně přesáhnout dalších pár hodin práce programátora/tes­tera/testera nasazeného klientem. Samozřejmě když si firma zadá web, kam mu denně přijde 30 lidí a kde si jednou za 3 měsíčně upraví pár textů, tam nemá TDD valný smysl, ukážu to klientovi v produkci a on řekne. Mezitím to uvidí 1, maximálně 2 návštěvníci, které by to teoreticky mohlo odradit.

Honza Marek

Jsem zvědav, jestli se tenhle seriál dostane někam dál než k základům, které se každý může za dvě hodiny naučit sám. Doufám, že ano. (P.S. Ano, všimnul jsem si, že toto je první díl.)

František Kučera

Jen mi přijde škoda, že jakmile tady přijde na řeč na testování, automaticky se mluví o jednotkových testech – přitom testování je daleko širší oblast (chápu, že když je potřeba sem dát nějakou ukázku, je lepší sem dát pár řádků unit testu, než hodinové video o testování Seleniem, ale aspoň zmínku by si to zasloužilo – v úvodním dílu popsat základní druhy testů a jejich smysl).
Jednotkové testy (tím je nechci zlehčovat) jsou spíš jen pomůcka pro programátora, aby si mohl stát za tím, co odevzdává, měl ověřené, že to funguje. Ale pro úspěch celého projektu jsou daleko důležitější komplexní testy funkčnosti a nakonec akceptační testy zákazníka. Že dopadnou jednotkové testy OK a že má programátor dobrý pocit, ještě neznamená úspěch celku – proto bych doporučoval „nevykrvácet“ na jednotkových testech – nevyplýtvat na ně příliš času a nadšení k testování a něco si nechat i pro ty další druhy testů. Aby to nedopadalo tak, že někdo sice pokryje jednotkovými testy „110% kódu“ ale ve výsledku mu to stejně nefunguje, protože už nezbyl žádný čas na testování celku (nebo tým usnul na vavřínech, že má všude zelené „fajfky“ a jiné testování se už „zapomnělo“).
P.S. a k těm chybám, které se „záhadně“ projeví jinde, než vznikly – těm se do do jisté míry (byť zdaleka ne 100%) předejít dobrým návrhem, nepsat aplikace kde „všechno souvisí se vším“ – nejdřív myslet na ten návrh a až potom na testy.

Aleš Roubíček

Když se mluví o testování v kontextu programátora, tak tou jsou samozřejmě unit testy a integrační testy, jiné testy by neměl mít na starosti programátor, ale tester (popř. zákazník – akceptační testy).
Ad. PS. TDD slouží jako nástroj pro lepší návhr a unit testy jsou spíše vedlejší produkt.

Jiří Knesl

děkuji za komentář, je k věci. Ano, oblast testování je tak rozsáhlá, že bych jen úvod a dělení mohl roztáhnout do řady článků. Mým cílem každopádně u tohoto seriálu je, aby programátor „položil ruce na klávesnici“, aby napsal alespoň nejaké testy, aby začal přemýšlet nad testovatelností kódu a aby začal co nejrychleji využívat výhod testování a postupně doplňoval pokročilejší partie.

Borek Bernard

Proč tohle není první odstavec článku? Ušetřil bys mi psaní :)

Sniper

Ja treba unit testy beru jako pojistku upgrade frameworku. Pokud mam aplikaci ze 100% pokrytou a upgradnu framework na novou verzi muzu jednoduchym spustenim testu zjistit, jestli se nekde neco nerozbilo.

Karel

Nelíbí se mi, jaké jsou vyjmenované alternativy testování. Ve skutečnosti to totiž nejsou alternativy, ale jednotlivé fáze testování, protože každá testuje něco jiného. V naší firmě jsou tyto fáze:
1. Unit testy – ke každému programu je připravena sada jednoduchých unit testů, které mají primárně za úkol ověřit, že program vůbec běží. Tedy zda umí založit nový záznam, přečíst data atd. Nekontroluje se ani tak správnost výsledků (to je u komplexního ERP prakticky nemožné), jako spíš fakt, že to běží. Občas se stane, že programátor chytře upraví nějakou DB tabulku a unit test úplně jiné úlohy na tom vyhučí – což je právě účel unit testů.
2. System test – to provádí programátor sám ručně. Předem si připraví scénář system testů, který mu odsouhlasuje klíčový uživatel zákazníka. Cílem je ověřit si, že aplikace funguje na vzorové úloze správně. Těch úloh je celá řada mají pokrýt běžné (=zamýšlené) použití.
3. UAT (User Acceptance Testing) – klíčový uživatel zákazníka provede sadu testů (sám si stanoví jakou) a prostě si aplikaci „zkusí“. Následně závazně potvrdí, že aplikace funguje. Jedná se prakticky o duplicitu System testů, ale provádí ji člověk, který bude aplikaci buď sám používat, nebo je alespoň „mluvčím“ skupiny lidí, kteří ji budou používat. Odchytí se tak problémy, kdy s číslem objednávky „1“ vše funguje, ale s „MT-721–101–161-A-12“ to padne na hubu (programátor nevěděl, že náš zákazník má poněkud svérázný názor na číslování objednávek).
4. Go-live. Aplikace se předá k užívání a uživatelé ji používají a tím zároveň testují. V této fázi se vždy najde plno chyb, protože uživatelé aplikaci vždy použijí jinak, nebo alespoň docílí naprosto neočekávané situace. Na výraz „neočekávané“ kladu důraz, protože to znamená, že se na ně lze těžko připravit předem. Chyby z této fáze obvykle nejsou kritické, ale bývá jich hodně. Kupříkladu teď jsme měli formulář, kde se podle zadaného čísla položky při ukládání automaticky vyplní několik políček – a uživatelé si proto nekontrolují, zda je v důležitých polích správná hodnota, protože ona se tam vždycky dotáhne. Pokud uživatel zadá neplatné číslo položky, formulář na to upozorní a nedovolí záznam uložit. Jenže se ukázalo, že pokud uživatel číslo položky opraví a zmáčkne save… automatické dotažení jednoho z údajů se nekoná. Zrada je v tom, že po prvním pokusu o uložení se hodnota null přepsala na prázdný řetězec, takže při druhém uložení si formulář myslel, že tam už uživatel sám něco vyplnil. Takže teď tenhle typ chyby známe, ale stejně nás nenapadá, jak to zužitkovat při testování. Akorát programátor už ví, že místo testu isnull tam má být isnull or length < 1.
Každá fáze testuje něco jiného. Unit test se nedá nahradit tím, že by tlupa pákistánců pracovala s aplikací. Stejně tak žádný unit test nenahradí tlupu pákistánců pokoušejících se aplikaci shodit.
A ještě jedna připomínka – o unit testech se často mluví jako o nástroji jak otestovat svoji aplikaci při jejím vývoji. To není pravda, s tímhle prvním testováním vám unit test nepomůže, na to jsou opravdu lepší ty debug hlášky. Unit test využijete až při dodatečných úpravách a předělávkách své aplikace. On vám totiž dokáže ověřit, zda vám něco základního nepřestalo fungovat. U aplikací s tisíci tabulkami je to neocenitelné, protože vy si upravíte jednu drobnost a vyhučí vám hromada unit testů naprosto nesouvisejících modulů. A o tom to je :-) Bez toho se občas stane, že vámi přidaná funkce pro vytváření nákupních objednávek výborně funguje, ale při měsíční účetní uzávěrce padne zaúčtování na hubu s chybou null hodnoty primárního klíče (kdo by to byl řekl, že při přecenění kurzových rozdílů otevřených závazků si aplikace tuto odchylku zapisuje jako další řádek objednávky).

Jiří Knesl

Děkuji za velmi podnětný komentář! Ano, způsobů testování jako je banda pákistánců, akceptační, výkonové, bezpečnostní, můžete najít celou řadu. Cílem této série je spíše hledání chyb „zevnitř ven“, tedy od kódu směrem k ostatním třídám. Vůbec není řešeno, zda to ve skutečnosti „dělá co má“, od toho jsou jiné nástroje.
Jak to máte řešené u Vás je zajímavý způsob, těchto postupů je celá řada, některé jsou řešeny v RUP, jinak třeba zase ve Scrumu, najede-li firma na extrémní programování, taky to není jen o unit testech.
Pokud udržujete projekt o tisíci(ích) tabulek se složitou logiku, samotné unit testy jsou nedostatečné, je nutné dám tomu koncept, test plan (master a iterační).
Jinak nesouhlasím s tím, že UT není dobrý při vývoji. Já sám používám UT velkou měrou místo debug hlášek a naopak mi to funguje dobře.

Karel Minařík

Bez těch opakovaných xenofobních odkazů na „bandy pákistánců“ by to vážně nešlo?!
–karmi

Jiří Knesl

Xenofóbní? No těm Pákistáncům bych se měl asi omluvit. Ikdyž jestli jsou podobní jako Indové, tak by si lepší označení než banda nebo tlupa nezasloužili. (o pracovní morálce Indů se už učí i na VŠ)
Jinak xenofobie je popisovana jako strach z cizinců, kdežto my to zde použili spíš výsměch, přesnější by proto bylo říct rasistické. Ne, že by to byla o něco lepší vizitka. :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.