Sdílená databáze, která tiše rozbíjí testovací pyramidu

Pro sledování výkonu se vyplatí měřit dobu spuštění, spotřebu baterie a vytížení paměti. Pomohou vám k tomu nástroje, které jsou součástí vývojových prostředí, a jednoduché záznamy přímo v aplikaci. Zaznamenejte si, kolik času uplyne od klepnutí na ikonu po zobrazení první obrazovky. Pokud přesáhne několik sekund, hledejte příčinu – často jde o příliš mnoho práce při startu, například načítání velkých dat nebo inicializaci knihoven, které nejsou potřeba.

Testů přes skutečné uživatelské rozhraní drž co nejméně. Jsou pomalé a křehké: stačí posunout tlačítko a přestanou fungovat. Piš je jen pro kritické cesty – přihlášení, dokončení interiéru objednávky, smazání účtu. Vždy hledej prvek podle stabilního identifikátoru, ne podle textu, který se překládá. Počkej na stav, ne na pevný počet sekund; pevné čekání je nejčastější důvod, proč testy na pomalém počítači padají. A když test spadne, podívej se nejdřív, jestli není chyba v testu samotném.

Vyhýbejte se sdílenému mutovatelnému stavu, kde to jde. Globální proměnné a objekty předávané mezi funkcemi, které je mění, dělají tok dat nepředvídatelným. Pokud funkce vrací novou hodnotu místo toho, aby přepisovala vstup, snáz se testuje a snáz se čte. Stejně tak dávejte přednost malým modulům s jasně vymezeným rozhraním před jedním velkým souborem, kde se všechno odkazuje na všechno.

Na co se vyplatí dát pozor při prvním rozhodování První jazyk by měl mít tři vlastnosti: jednoduchou syntaxi, dostatek materiálů v češtině nebo angličtině a aktivní komunitu. Jednoduchá syntaxe znamená, že nemusíš řešit složité typové systémy nebo ruční správu paměti dříúložné prostory v malém bytě, než pochopíš základy. Dostatek materiálů znamená, že když narazíš na chybu, najdeš vysvětlení. Aktivní komunita znamená, že se dostaneš k odpovědím na otázky, které ještě nikdo nezodpověděl.

Rozklad na malé kroky sám o sobě odhad nezpřesní, pokud ho neudělá člověk, který bude práci skutečně dělat. Manažer ani analytik nedokáže spolehlivě odhadnout, kolik času zabere implementace, protože nevidí do . Proto je lepší nechat odhad napsat řešitele a teprve potom ho porovnat s ostatními. Pokud se odhady dvou lidí liší více než dvojnásobně, není to důvod k hádce, ale signál, že zadání není dost jasné.

U end-to-end testů je situace jiná. Ty často potřebují databázi, která se podobá produkci, včetně objemu a rozložení dat. Sdílená instance tady může dávat smysl, ale musí být oddělená od vývojové a integrační. Zásadní je, aby end-to-end běhy neběžely současně s jinými zápisy. Naplánuj je mimo pracovní špičku nebo použij samostatný klon. Pokud to nejde, raději omez počet paralelních běhů, než aby selhávaly kvůli zámkům.

Odhady v softwarových projektech selhávají především proto, že lidé odhadují práci, kterou ještě nikdy nedělali, a zaměňují ji za práci, kterou znají. Nejčastější chyba je odhadovat v hlavě během porady, kde nikdo nic nepočítá a všichni jen souhlasí s prvním číslem, které zazní. První krok k lepším odhadům je přestat odhadovat celky a začít rozkládat práci na části, které trvají nejvýše dva dny.

Vyhněte se odhadům, které zní příliš přesně. Tvrzení, že to bude hotové za sedmnáct dní, je falešná jistota. Poctivější je rozmezí a informace, co se stane, když se něco pokazí. Zároveň platí, že čím déle projekt běží, tím méně přesné odhady jsou, protože přibývá neznámých. Pokud se odhad začne výrazně rozcházet se skutečností, je lepší včas zmenšit rozsah než posouvat termín donekonečna.

Poslední věc, kterou je snadné podcenit, je monitoring. Sdílená databáze bez přehledu o tom, kdo ji zrovna používá, je černá skříňka. Zaznamenej, které testy se připojují, jak dlouho běží a jak zařídit malou kuchynié dotazy spouštějí. Když se pyramida začne sypat, uvidíš to v datech dřív, než ti to řekne někdo z týmu. Bez tohoto přehledu budeš jen hádat, která vrstva testů je ta, co zlobí.

Sdílená databáze mezi týmy vypadá jako úspora. Jeden stroj, jedna sada dat, žádné kopie. Jenže testovací pyramida stojí na předpokladu, že jednotlivé vrstvy testů jsou izolované a rychlé. Jakmile se o stejnou instanci začnou prát vývojáři, testeři a CI pipeline, pyramida se začne drolit od základů. Unit testy přestanou být unit testy, protože potřebují připojení k síti. Integrační testy závisí na datech, která někdo jiný právě přepsal. A end-to-end testy padají z důvodů, které s kódem nemají nic společného.

Začni tím, co chceš skutečně dělat. Pokud tě láká tvorba webových stránek, potřebuješ jazyk, který běží v prohlížeči. Pokud chceš zpracovávat data a tabulky, hledej jazyk s dobrými knihovnami pro výpočty. Pokud chceš ovládat hardware nebo psát rychlé aplikace, budeš potřebovat něco jiného. Konkrétní cíl je důležitější než abstraktní „chci se naučit programovat". Bez cíle skončíš u tutoriálů, které tě nikam neposunou.