U integračních testů se zaměřte na hranice systému: přístup k datům, komunikaci s externími službami a serializaci. Používejte skutečnou databázi, ideálně stejnou, jakou běží v produkci, ale s oddělenými testovacími daty. Nepodvádějte s transakcemi, které se po testu rollbackují — to sice zrychlí běh, ale neodhalí problémy s únikem spojení nebo s čistěním dat. Pro end-to-end testy vyberte jen ty nejdůležitější uživatelské cesty, třeba registraci, objednávku nebo úhradu. Více než deset takových testů začíná být neudržitelných.<br>
<br>
<br>
<br>
Pamatujte, že pyramida není statická. S tím, jak se mění architektura aplikace, mění se i poměr testů. Na začátku projektu můžete mít více integračních testů, protože ještě nemáte stabilní rozhraní pro mockování. Po pár měsících se hranice ustálí a vy je převedete na jednotkové. Klíčové je pravidelně revidovat testovací sadu: jednou za kvartál se podívejte, které testy nikdy neselhávají, které opakovaně vyžadují opravy a které už neodpovídají aktuálnímu chování systému. Testy, které nikdo nespouští nebo jim nikdo nerozumí, jsou horší než žádné — dávají falešný pocit bezpečí.<br>
<br>
<br>
<br>
<img src="https://freestocks.org/fs/wp-content/uploads/2016/08/two_men_discussing-1024x683.jpg" style="max-width:400px;float:left;padding:10px 10px 10px 0px;border:0px;">Důležitá je i správa oprávnění databázového účtu, který aplikace používá. Nikdy nepřipojujte k databázi s právy administrátora, pokud to není nezbytné. Vytvořte samostatný účet s minimálními právy – jen pro potřebné operace (SELECT, INSERT, UPDATE, DELETE pro konkrétní tabulky). Tím omezíte škody, i když útočník najde zranitelnost. Stejně tak byste měli aplikaci běžet v izolovaném prostředí, kde nemá přístup k systémovým souborům.<br>
<br>
<br>
<br>
Prvním krokem je vždy použití parametrizovaných dotazů. Místo abyste do SQL příkazu vkládali hodnoty z uživatelského vstupu přímo, použijte připravené dotazy – prepared statements. Ty zajistí, že se vstup interpretuje jako data, nikoli jako součást SQL syntaxe. V jazycích jako PHP, Python nebo Java existují pro tuto techniku nativní API. Pokud používáte ORM, je 99 % dotazů automaticky parametrizováno, ale i tak je nutné si ověřit, jak váš framework s vstupy pracuje.<br>
<br>
<br>
<br>
Psát testy bez promyšlené struktury připomíná stavbu domu bez projektu: ze začátku to vypadá nadějně, ale s každou další funkcí se začnou objevovat praskliny. Testovací pyramida není dogma, ale praktický nástroj, který vám pomůže rozhodnout, kam investovat čas a úsilí. Základní princip je jednoduchý: čím nižší vrstva, tím rychlejší a levnější testy, a proto jich má být nejvíce. Na vrcholu pyramidy stojí testy pomalé a drahé, kterých by mělo být minimum.<br>
<br>
<br>
<br>
Kde nejčastěji chybujete a jak to opravit Klasickým prohřeškem je stavba SQL dotazů pomocí řetězců, kde spojujete text a proměnné. Například: SELECT * FROM uzivatele WHERE jmeno = '".$_GET['jmeno']."'. Tento kód je extrémně zranitelný. Útočník do jména zadá: ' OR '1'='1 a získá všechny uživatele. Dalším častým problémem je neověřené použití vstupů v příkazech jako ORDER BY nebo LIMIT. I tyto části dotazu lze zneužít, pokud se data nevalidují jako číselné hodnoty nebo bezpečné identifikátory sloupců.<br>
<br>
<br>
<br>
Další praktický krok je nastavit si pro každý jazyk vlastní terminál nebo příkazovou řádku. Mnoho projektů má skripty pro build spouštěné v různých prostředích. Pokud máte jeden terminál, který se přepíná podle aktuálního souboru, ušetříte si spoustu klikání. V praxi to znamená, že když stojíte v souboru Python, terminál se automaticky spustí s virtuálním prostředím. Když přejdete na JavaScript, terminál se přepne do Node.js prostředí. To vám umožní spouštět testy a linting bez ručního zadávání příkazů. Ale pozor, tohle vyžaduje, aby byl každý jazyk izolovaný ve svém vlastním adresáři nebo alespoň měl jasně oddělené konfigurační soubory.<br>
<br>
<br>
<br>
Při zavádění pyramidy se vyhněte dvěma extrémům. První je snaha pokrýt absolutně všechno testy — to vede k tomu, že strávíte více času údržbou testů než vývojem funkcí. Druhý extrém je testovat jen to, co je zrovna v módě, nebo co umíte. Dobrým kompromisem je nastavit si firemní směrnici: jednoduché funkce bez rizika nemusí mít testy vůbec, ale kritické výpočty a platební toky ano. Pak se vyplatí investovat do měření pokrytí, ale ne na úrovni řádků — sledujte pokrytí větví a rozhodovacích podmínek.<br>
<br>
<br>
<br>
Když zákazník požádá o odhad času, většina z nás automaticky vsadí na optimismus. V duchu si řekneme, že to stihneme dřív, a sdělíme termín, který nás pak dostane pod tlak. Výsledek? Zpoždění, omluvy a zákazník, který vám přestane věřit. Přitom stačí změnit způsob, jakým o čase mluvíte, a komunikace se stane nástrojem důvěry místo zdrojem stresu.
