Ruční testování nebo automatizace: co u aplikací odhalí víc

Testování aplikací začíná u rozhodnutí, co vůbec ověřovat. Než napíšeš první test, sepiš si seznam rizik: co se stane, když aplikace spadne při přihlášení, když ztratí data, když pošle platbu dvakrát. Testy nemají pokrýt všechno, mají pokrýt to, co bolí nejvíc. Praktický postup je rozdělit aplikaci na vrstvy – datová logika, rozhraní, integrace – a pro každou zvolit jiný typ ověření. Bez tohoto rozdělení skončíš u hromady testů, které sice běží, ale nic nechrání.

Asynchronní logiku držte mimo komponenty. Načítání dat patří do thunků, middleware nebo do nástroje, který vytváří akce ze požadavků. Komponenta má pouze spustit akci a zobrazit stav načítání, chyby nebo dat. Typická chyba je, že vývojář volá fetch přímo v efektu a výsledek ukládá přes dispatch do více klíčů. Vzniká nekonzistentní stav, kde se část dat aktualizovala a část ne. Řešením je jedna akce, která nese celý výsledek, a jeden reducer, který ho zpracuje atomicky.

Začít přispívat do open source vypadá složitě jen do chvíle, než pochopíte, že nejde o vstup do nějakého uzavřeného klubu. Projekty naopak nové přispěvatele aktivně hledají, protože bez nich stagnují. Rozdíl mezi těmi, kdo přispívají, a těmi, kdo jen přemýšlejí o tom, že by mohli, je většinou v tom, že první jmenovaní si našli malý, konkrétní problém a vyřešili ho. Zbytek je řemeslo, které se dá naučit.

Než napíšete řádek kódu, přečtěte si soubor s pravidly pro přispěvatele a průvodce stylem. Zjistěte, jak projekt přijímá změny – jestli přes forkovaný repozitář a větev, nebo jinak. Většina projektů dnes vyžaduje, abyste pracovali ve vlastní větvi odvozené od hlavní vývojové linie, ne přímo v ní. Zkontrolujte také, zda už někdo podobný problém neřeší v otevřených návrzích na změnu. Duplicitní práce se odmítá stejně rychle jako nekvalitní kód.

Po přijetí změny se nebojte ptát, co dál. Většina projektů vede seznam úkolů vhodných pro nováčky. Přispívání je dovednost jako každá jiná – první krok je nejtěžší, druhý už jde snáz. Vytrvejte u jednoho projektu alespoň několik měsíců. Naučíte se jeho architekturu, získáte důvěru správců a příště už budete řešit zajímavější problémy než překlepy.

Nakonec nastavte krátkou revizi pyramidy při každém větším plánování. Stačí půl hodiny a otázka, zda rozložení testů odpovídá aktuálním rizikům. Pokud ne, upravte ho hned, dokud je změna malá. Pyramida, která se hýbe spolu s požadavky, zůstává užitečným nástrojem. Pyramida, která se hlídá jen podle počtu testů, se dřív nebo později stane jen dalším místem, kde se hromadí práce, kterou nikdo nechce udržovat.

Responzivitu netestujte jen zmenšováním okna. Otevřete vývojářské nástroje, zapněte zobrazení mřížky a projděte šířky 320, 480, 768 a 1200 pixelů. Sledujte, kde se obsah láme a kde přetéká. Když něco nefunguje, nepište další media query — nejdřív zkontrolujte, zda má rodičovský prvek správný display a zda potomek nemá min-width, který brání zmenšení. Většina problémů vzniká na těchto dvou místech.

Než napíšete první řádek kódu Přečtěte si soubor s pokyny pro přispěvatele. Bývá pojmenovaný jako CONTRIBUTING a obsahuje pravidla pro formátování, větev, do které se posílají změny, a způsob testování. Ignorování tohoto souboru je nejčastější důvod, proč je pull request zamítnut během několika minut. Stejně důležité je projít si existující Issues a pull requesty, abyste neřešili něco, co už někdo jiný rozpracoval. Někdy stačí napsat do komentáře pod Issue krátkou zprávu, že na tom pracujete, a domluvit se na postupu.

První přijatý pull request je zlom. Otevře vám dveře k dalším úkolům, získáte přístup k diskusím a postupně vás začnou brát jako součást týmu. Přispívání do open source není soutěž o největší počet commitů, ale dlouhodobá spolupráce. Stačí začít malou opravou, dodržet pravidla projektu a vydržet u něj dost dlouho na to, aby si vás ostatní všimli.

Prvním krokem není hledat projekt, ale oblast, které už trochu rozumíte. Pokud píšete v Pythonu, nemá smysl začínat u kódu v C. Projděte si repozitáře, které sami používáte, a podívejte se do sekce s otevřenými Issues. Hledejte štítky jako „good first issue" nebo „help wanted". U nich bývá popsáno, co je potřeba udělat, a správce projektu obvykle počítá s tím, že přispěvatel je nový. Vyhněte se diskusím, kde se řeší architektura nebo dlouhodobé směřování projektu — tam se nováček těžko prosadí a snadno se ztratí.

Po odeslání pull requestu čekejte na reakci. Může trvat dny i týdny, protože správci dělají na projektu ve svém volném čase. Když dostanete připomínky, berte je věcně a upravte kód podle nich. Obrana a vysvětlování, proč je vaše řešení správné, vede jen k zbytečným konfliktům. Pokud projekt o změnu nemá zájem, není to osobní selhání — zkuste jiný projekt nebo jinou Issue. Vytrvalost a schopnost přijmout zpětnou vazbu nakonec rozhodují víc než technické znalosti.