Edytujesz 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í.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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í.<br><br>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.