{jcomments on}Další technika testování, která úzce souvisí s testování ekvivalence, se zaměřuje na chyby, které mohou nastat při validaci vstupních dat.

Validace vstupu je důležitá součást každé aplikace, která ale (pochopitelně) nebývá součástí požadavků zákazníka. Implementace validací se tak nějak přirozeně předpokládá. A proto je důležité její správné testování. Základ zde představuje kontrola správné reakce aplikace na vložení nesmyslné hodnoty. Z pohledu testování je pak důležité určit, co to vlastně ta nesmyslná hodnota je.

Jako první samozřejmě každého napadne situace, kdy vložená hodnota neodpovídá typu pole. Tedy například pokud do číselného pole vložím text. Aplikace musí na tuto situaci zareagovat "adekvátně". Schválně volím toto slovo, protože možných reakcí je víc a jen některé se dají označit za adekvátní. Zcela špatné samozřejmě je, pokud aplikace po vložení takového nesmyslného vstupu spadne. Ovšem zcela stejně špatné je chování, kdy aplikace nezareaguje nijak. Tedy buď hodnotu bez jakékoli chybové hlášky zpracuje a případně i uloží, nebo zůstane stát na vstupním formuláři s chybným vstupem bez toho, že by jakýkoli způsobem zobrazila, co je špatně.

Snažím se tu říct, že testování nesmyslných hodnot je vlastně testování správného ošetření chybových stavů v aplikaci vzniklým nevalidním vstupem. Pro každou takovou situaci by měla existovat odpovídající chybová hláška, která uživatele upozorní na to, co je špatně.

Tak zpět  tomu, co je to nesmyslná hodnota. Vložení hodnoty neodpovídající typu vstupního pole je základ. Vychází se přitom z toho, jak je dané pole definováno na straně vývojáře (tedy v kódu nebo v databázi). Pokud tyto informace nemáme, pak se musíme spolehnout na vlastní odhad. Většina polí je ale tak zřejmá, že není moc o čem přemýšlet. Například pole pro zadání datumu a času by vám nemělo povolit vložit text ani hodnotu, která neodpovídá očekávanému formátu. Myslím tím například vložení hodnoty 20110307, která může být v určitých případech vnímána jako validní datum do položky, kde stejné datum očekávám v podobě 07/03/11. Vložení textu do číselného pole jsem tu už zmiňoval.

Ovšem pouze s typem vstupního pole nevystačíme. Některé hodnoty mohou odpovídat typu vstupního pole a přesto by měly být označené jako chybné. Klasický příklad může být pole pro zadání e-mailové adresy. Toto pole bude textové, ovšem hodnota do něj vložená musí splňovat další podmínky. Formát e-mailové adresy je asi dostatečně známý, takže nemá cenu se jím blíže zabývat. Při testování nesmyslného vstupu do tohoto pole se může počet testů vyšplhat až na číslo okolo šesti sedmi.

Podobně je to například u pole pro zadání telefonního čísla. To na první pohled svádí k tomu, aby šlo o čistě číselné pole. Ovšem nemělo by to tak být. Musíme si uvědomit, že telefonní číslo můžeme zadat i této podobě +420603603603. V tu chvíli se už dostáváme do textového formátu. Samozřejmě záleží na tom, jaký formát je zde od uživatele vyžadován. Vývojář může uživatele nutit k tomu, aby hodnotu telefonního čísla zadal pouze jako číselnou. Pak tu ale právě musí existovat správná validace vstupní hodnoty. Aplikace musí korektně zareagovat i na případné mezery zadaném telefonním čísle atd.

Samostatnou kapitolou při testování nesmyslných hodnot představují datumová pole. Formát datumu a času je věcí dosti proměnnou a už v tomto směru je potřeba takový vstup otestovat (to jsem tu už zmínil). Ovšem tato vstupné pole umožňují i vložení hodnot, které vypadají formálně správně, přesto jsou nesmyslné. Pokud do pole pro vložení času zadáte hodnotu 25:78, pak jde samozřejmě o chybný časový údaj a aplikace na to musí správně reagovat. V případě datumu je situace ještě o něco zajímavější. Například hodnota 30.2.2011 je nesmyslná čistě jen proto, že měsíc únor nikdy nemůže mít 30 dní. Ovšem hodnota 29.2.2011 je nesmyslná proto, že rok 2011 není přestupný (tedy například hodnota 29.2.2008 by byla validní). Takto je samozřejmě možné testovat nesmyslné datumy pro všechny měsíce v roce.

U datumových polí je častá i situace, kdy nám dvě datumová pole vymezují nějaký interval (myšleno začátek nějaké činnosti a konec). Zde by měl následovat test chování aplikace v okamžiku, kdy datum představující konec intervalu je starší než datum začátku.

Mohlo by se zdát, že nesmyslné hodnoty na vstupu má smysl testovat jen u aplikací s nějakým GUI, u které uživatel zadává vstupní data pomocí nějakého formuláře. To je samozřejmě omyl. Naprosto stejně se testují i vstupy například formou vstupního souboru a stejné testy jsou i součástí testování integrace mezi systémy (kdy se ověřuje validace vstupujících zpráv z externích systémů). Zkrátka všude, kde se očekává validace vstupních dat, je vhodné tuto validaci testovat pomocí nesmyslných hodnot.