Každý program, kde to dává smysl, by měl obsahovat zároveň sadu vstupů, na kterých jste ho otestovali + jak to na daných vstupech má dopadnout. To slouží jednak jako kontrola, že se Váš program chová správně a druhak jako součást návodu na jeho používání (typicky je pro uživatele rychlejší se podívat na ukázkový vstup, než zkoumat formální popis vstupů).
Pozor na to, že za otestování programu je zodpovědný jeho autor - ne ten, komu ho předává. (Tzn. ne "Aha, zákazník si při předání programu nevšiml, že padá na vstupu 5.2387 - tak to má smůlu." ;)) V praxi ve větších programátorských firmách bývají přímo testerská oddělení - a každá část programu má sepsaný seznam "test-cases", kterými to musí projít. Samozřejmě snaha je tyto testovací případy automatizovat (tak zhruba funguje CodEx). Ale někdy to není možné - typicky když je nutný uživatelský vstup myší a další lidská interakce. Pak testovací příklad obsahuje popis, co má tester udělat a jak by se měl program chovat.
Vy naštěstí píšete program výrazně kratší, takže na to nepotřebujete cizí testery. Je ale dobré již při tvorbě programu uvažovat nad tím, jak by se měl testovat - a zahrnout tam všechny speciální i okrajové vstupy. Z hlediska zápočťáku je také důležité vidět, že jste schopní tyto vstupy vymyslet.
Některé zápočťáky jako například hry mají jiný typ vstupu: např. ovládání klávesnicí. U nich nedává tak dobrý smysl vytvářet nějaké testovací vstupy. Na druhou stranu i tento typ programů se dá testovat. Pro ně je vhodné napsat sadu úkonů, které se mají otestovat a jak by měly dopadnout. Dané úkony by měly být poměrně jasně popsány, jako např.: "10x zmáčkněte šipku doprava a pak šipku dolů --> na obrazovce by se mělo objevit číslo 32", nebo např.: "nechte hada narazit do zdi --> had zemře a objeví se znovu uprostřed hracího pole a vlevo dole ubyde počet životů o 1".
Zkuste se vždy zamyslet nad nejen typickými, ale i okrajovými situacemi. Třeba kdyby to psal někdo, koho nemáte rádi a chtěli jste mu tam najít chybu. Co byste zkusili zadat? ;)
