Testy máte v jazyce, kterému ve firmě nikdo nerozumí
Testy se nestanou bezcennými ze dne na den. Nejprve odejde člověk, který je psal. Chvíli je ještě někdo opravuje podle vzoru – zkopíruje existující test a změní v něm hodnoty. Pak se objeví chyba, kterou tímto způsobem opravit nelze, a nikdo se do toho nechce pustit, protože danému jazyku pořádně nerozumí.
Test se přeskočí. Potom druhý. Za několik měsíců se celá sada v pipeline vypne, protože „stejně pořád svítí červeně“. Roky práce zmizí, aniž by o tom někdo rozhodl.
Běžný problém: sadu nemá kdo udržovat
Testovací sada není hotový produkt, který jen tak běží. Je to živý kód, který se mění spolu s aplikací. Nová důležitá funkce může vyžadovat nový test a změna obrazovky může ovlivnit dotčené scénáře.
To znamená, že někdo musí umět sadu otevřít a upravit – a ne jednou za rok, ale průběžně. Pokud to umí jediný člověk, sada je na něm závislá. Pokud to neumí nikdo, sada už nežije, jen to zatím nikdo neřekl nahlas.
Typický případ: testy jsou v jiném jazyce, protože se to tak kdysi dělalo nebo je externí dodavatel psal ve svém stacku. Vývojáři ve firmě dnes píšou v Pythonu nebo TypeScriptu. Sadu formálně „mají“, ve skutečnosti se jí však nikdo nedotkne.
Jak přenést testy do vhodného jazyka
Sadu přeneseme do jazyka, kterému váš tým skutečně rozumí.
Nepřekládáme přitom řádek po řádku. Hodnotu nesou scénáře a ověření – znalosti o tom, jak se má produkt chovat, které jste sbírali celé roky. Právě ty přenášíme. Kód, který je dnes zapisuje, bývá zároveň tím, co činí sadu neudržitelnou, takže ho do nové nekopírujeme.
Volba cílového jazyka není otázkou módy:
- Python může dávat smysl týmu, který ho už používá nebo potřebuje přístupnější syntaxi. Playwright i Selenium mají oficiální rozhraní pro Python, konkrétní knihovny a integrace je však třeba porovnat s potřebami projektu.
- TypeScript volíme tehdy, když mají testy žít vedle frontendu a rozšiřovat je má stejný tým, který píše aplikaci. Testy jsou pak ve stejném repozitáři a ve stejném jazyce jako produkční kód – nová funkce a její test vznikají společně.
- Robot Framework může dávat smysl, pokud vhodně pojmenovaná klíčová slova pomohou s čitelností scénářů i mimo vývojářský tým.
Cílový jazyk volíme podle zkušeností týmu, technologií produktu a dostupných integrací, ne podle našich preferencí. Rozhoduje, v čem dokáže tým sadu dlouhodobě udržovat.
Novou sadu navrhneme pro snazší údržbu – s přiměřenou vrstvou objektů stránek nebo komponent, stabilními identifikátory a oddělenými testovacími daty. Přenos probíhá postupně podle priority a mapa pokrytí určuje, které regresní scénáře ještě kontroluje stará sada a které už nová.
Co vám čitelná sada přinese
Sadu, kterou tým umí číst. Když test selže, vývojář může snadněji zjistit, co ověřuje. U důležité nové funkce může tým doplnit test, aniž by nejprve musel překonávat bariéru cizího jazyka.
Tím se snižuje závislost na jediném člověku – vašem i externím. Sada je ve vašem repozitáři, v jazyce, který tým zná, a má dohodnutou dokumentaci. Schopnost samostatně ji rozšiřovat pak závisí na předání a kapacitě týmu.
Další krok
Řekněte nám, v čem jsou testy dnes a v čem píše váš tým. Ozvěte se nám – navrhneme cílový jazyk i pořadí přenosu a doporučení zdůvodníme.