Testování se určitě řadí mezi dobré praktiky vývoje softwaru (best practices). Další takovou praktikou je např. programovat objektově, používat vícevrstvou architekturu a podobně. Některé praktiky bychom měli dodržovat opravdu ortodoxně, např. pro psaní neobjektového kódu existuje opravdu jediný důvod a tím je neznalost programátora. Testování je velmi důležité a v určité části projektu dokonce nepostradatelné. Na druhou stranu, v prvních fázích projektu (a to zejména u start-upů), kdy se hraje na čas, funkčnosti aplikace se často mění, a je třeba aplikaci co nejdříve spustit, není vůbec dobrý nápad testy psát.

Zaměřme se nyní na to, co na aplikaci testujeme. Typů testů je hned několik. Obvykle nepokrývají úplně všechny možné scénáře (všechen kód). Hovoříme o procentuálním pokrytí testy (code coverage), většinou kritických částí aplikace. Čím větší aplikace je, tím více typů testů potřebuje Obvykle testují univerzální knihovny, nepíšeme je pro kód specifický pro danou aplikaci. Jednotkové testy testují třídy, přesněji jejich metody, jednu po druhé. Předávají jim různé vstupy a zkouší, zda jsou jejich výstupy korektní Tento typ testů je naopak úplně odstíněn od toho, jak je aplikace uvnitř naprogramovaná, jsou to tedy blackbox testy (nevidíme dovnitř). Každý test obvykle testuje určitou funkčnost, např. test pro psaní článků by testoval jednotlivé use cases s tím spojené (předat článek ke schválení, schválit článek, zamítnou článek, publikovat článek jako administrátor...). V dnešní době dosahují aplikace již poměrně vysoké komplexnosti a velmi často bývají rozdělené do několika služeb, které spolu komunikují a jsou vyvíjené zvlášť. Právě integrační testy dohlíží na to, aby do sebe vše správně zapadalo. I když aplikace funguje dobře, na produkčním prostředí podléhá dalším vlivům, se kterými musíme rovněž počítat. Např. že by měla zvládat obsluhovat tisíc uživatelů v jeden okamžik. To bychom provedli zátěžovým testem, který spadá mezi systémové testy.

Jako černou skříňku (black box) označujeme stav, kdy informace dostupné testerovi spočívají ve znalosti vstupů do aplikace a znalosti očekávaných výstupů. Tester nezná vnitřní logiku aplikace a jeho pohled je z velké části uživatelský. Testování se v tomto případě nejčastěji opírá o uživatelské požadavky, obvykle zpracované do určité formy business analýzy. Smyslem testů je ověřit, že očekávané chování (definované právě vstupy a výstupy) odpovídá chování skutečnému. Bílá skříňka (white box) znamená, že tester má přístup ke všem informacím včetně zdrojového kódu. Testování v tomto případě z větší části spočívá na testování právě samotného zdrojového kódu. To může být až na úrovni čisté revize kódu bez toho, že by aplikace byla spuštěna. Znalost vnitřní logiky aplikace dává testerovi možnost otestovat i situace, které nejsou z vnějšího pohledu patrné. Jinak řečeno mnohem lépe se pokrývá testy podmínkový strom, který jako tester vidím v konkrétní podobě než když mám o něm jen nejasnou představu danou definovanými výstupy.

Musí testovat člověk, nejde převést na člověka.

Usability testy se zaměřují na to, jak snadno a efektivně mohou uživatelé interagovat s vaší aplikací. Tyto testy obvykle zahrnují reálné uživatele, kteří provádějí různé úkoly a poskytují zpětnou vazbu.

Testování výkonu, někdy zkráceně “perf testing”, je proces prováděný za účelem zjištění, zda určitý produkt bude dobře vykonávat očekávané procesy při různém pracovním zatížení. To může mít podobu testování výkonnosti webových stránek nebo testování výkonnosti při testování softwaru, v závislosti na daném produktu.

Testování výkonnosti je určeno především k odhalení chybných parametrů výrobku, které lze změnit již v počáteční fázi životního cyklu výrobku, aby se předešlo větším problémům v budoucnu. To se často označuje jako hledání úzkých míst, což je jedna složka, která brzdí celkový výkon softwaru.

Testy výkonu webu jsou nezbytné, aby vývojáři mohli zúčastněným stranám poskytnout spolehlivé informace o výkonu aplikace a předpovědět, jak bude aplikace reagovat na různé úrovně provozu.

Profiler je nástroj, který se používá k analýze výkonu programu. Shromažďuje data o tom, jak program běží, včetně informací o tom, jak dlouho trvá spuštění jednotlivých funkcí, kolik paměti program používá a jak často se používají různé části kódu. Tato data lze poté použít k identifikaci úzkých míst v programu a ke zlepšení jeho výkonu. Takhle to vypadá ve visual studiu

Test-Driven Development (TDD) je přístup k vývoji software, který klade důraz na psaní testů před samotným psaním kódu. Jde o iterativní proces, který se dá shrnout do těchto kroků:

1. Napsat test
2. Spustit test
3. Napsat kod
4. Spustit testy
5. Refakterovat kod
6. Opakovat

Tento cyklus psaní testů, psaní kódu a refaktorování pomáhá zajistit, aby kód byl dobře navržený, testovatelný a splňoval požadavky.