Každý ví, jak udělat skvělé testování

V minulosti jsem si myslel, že testování bylo obtížné, že k tomu, abyste se naučili provádět správné testování, potřebujete značnou praxi. Před několika dny jsem si uvědomil, že to není správné; každý programátor již ví, jak testovat. V tomto článku představuji malý recept, který umožňuje komukoli psát vynikající testy od dnešního dne.

První nápověda

První náznak od strýce Boba jsem se dozvěděl před několika týdny. Učil jsem se z jednoho z jejich videí a slyšel jsem následující otázku:

»Který test píšete jako první?

Tato otázka mě překvapila, protože mám mnohaleté zkušenosti s psaní testů a nikdy jsem si na tuto otázku neptal. Ale strýček Bob měl pravdu. Odpověď na tuto otázku však byla také překvapivá a úžasně jednoduchá:

»Který výrobní kód byste napsali jako první?

Téměř ve stejnou dobu, kdy odpovídal na testovací zápis, jsem sám odpověděl: ten, který vás nutí psát první bit kódu.

Pokud budete postupovat podle TDD (měli byste), existuje pravidlo, které říká: nemůžete psát žádný produkční kód, dokud nemáte nevyhovující test. A pak, když selže tento test jednotky, nemůžete napsat více kódu, než je dostačující pro úspěšné provedení testu. To znamená, že nemůžete začít psát produkční kód; nejprve musíte napsat jeden test. A co je to za test? Jednoduchý, ten, který vám dává omluvu k napsání kódu, který potřebujete.

Nevíte, kde začít psát test? Napište ten, který vám umožní napsat požadovaný kód. To je jednoduché.

Recept

To byl první tip, který jsem měl: každý ví, jak napsat první test. Je to proto, že každý už má schopnosti to udělat: každý zkušený programátor ví, jak začít s kódováním, takže každý ví, který je první kus kódu, a co tedy nejdříve otestovat.

Je tedy možné, že každý ví, jak v každém případě dělat dobré testy?

Krok 1: První testy

Už máme recept na testy. Je to nejprve napsat testy, které nám dávají omluvu napsat kód. Dobře, možná to bude zpočátku pomalé, ale trochu si procvičte. Přijměte disciplínu TDD a vynakládejte úsilí na napsání testů dříve. Neexistuje lepší okamžik v projektu, který by se začal učit řádnému testování.

Krok 2: Měřítko velkého kódu

Co se stane, pokud již máte rozsáhlou aplikaci nebo objevíte chybu? Co se stane, pokud nemáte širokou základnu testů, které vám pomohou při provádění testů?

Tady tip psaní testu, který vám dává omluvu k napsání kódu, není snadné sledovat. Vypadá to tak komplikovaně a je mnohem jednodušší spustit aplikaci a ručně otestovat nejnovější změny, které jste provedli. Ale to je také odpověď. Protože víte, jak testovat aplikaci ručně, víte, co musíte testovat (a co netestovat). A to je to, co musíte napsat.

Nikdy nenapsáme velký kus kódu najednou; my všichni, téměř všichni, se tomu vyhneme. Místo toho píšeme malou část kódu. Poté otevřeme aplikaci, navigujeme, zavedeme data a nakonec vyhodnotíme, zda se kus kódu chová správně. A znovu opakujeme, dokud nedokončíme funkci.

Že iterativní je předchůdcem TDD bez testování. Co tedy musíme udělat? Snadné, namísto ručního testování aplikace, píšeme kód, který nás provede stejnou operací.

Provádíte přihlášení do aplikace? Spotřebujete službu? Napište vysmívat se službě. Viděl jsem mnohokrát programátory, kteří vytvářejí falešné přihlašovací údaje, aby mohli ručně otestovat svůj software. Můžete to udělat ručně a riskovat, že se k tomu dopustíte, nebo můžete věnovat trochu úsilí abstraktům této funkce, abyste ji mohli rychle zesměšňovat.

Navigujete v uživatelském rozhraní? Změna pohledu? Vyplňujete formulář? Opakujte stejné kroky s testem. Váš test vyberte pohled, ve kterém funkce funguje, a vyplňte formuláře za vás. Může to vypadat obtížně, pokud to uděláte poprvé, ale pokud to uděláte ručně a znáte kód, víte, co přesně se provádí v testu, aby aplikace dosáhla bodu.

Vyvíjíte API? Žádné uživatelské rozhraní? Vsadím se, že používáte Postman nebo podobný nástroj k ručnímu testování. Udělejte totéž ve vašem testu. Použijte MockMCV, Supertest nebo jakýkoli nástroj, který je k dispozici ve vašem softwarovém zásobníku. Provádějte volání API přímo ze svého testu a přečtěte si výsledek. A samozřejmě, mám pravdu, když říkám, že nekontrolujete, že je každé pole v odpovědi v pořádku? Nedělejte to ani v testu. Místo snímkování nebo podobně používejte nástroje, jako je Jsonpath, zkontrolujte pouze pole a hodnoty, které jsou relevantní pro váš test.

Pokuste se držet své ladicí schopnosti po celou dobu; jsme moudřejší, než jsme si uvědomili. Využijte těchto znalostí a nechte svůj kód dělat to, co byste udělali ručně, nic víc, nic méně.

Krok 3: Odstraňte odkazy na uživatelské rozhraní

To se zdá trochu složitější, protože se na začátku necítí přirozeně, ale je to právě naopak.

Recept v kroku 2 říká, že byste měli reprodukovat to, co děláte ručně. A bezpochyby používáte uživatelské rozhraní. Co znamená odstranění odkazů na uživatelské rozhraní?

Trochu sebereflexe. Co si myslíte, když komunikujete s uživatelským rozhraním? Myslíte si: Chystám se kliknout na toto pole, napsat tyto klíče a stisknout tlačítko Hledat? Nebo si myslíte: Budu dělat toto hledání? Ten druhý, že? To je to, co musíte udělat.

Namísto psaní v testu přímé volání do uživatelského rozhraní vytvořte knihovnu nebo rozhraní pro vyjádření toho, co si myslíte. Napište funkční volání: hledejte místo manipulace s uživatelským rozhraním. A pak implementovat přesné chování do funkce.

Při psaní a používání této abstrakční knihovny dosáhnete dvou cílů. První je, že testovací kód je čitelnější než psaní přímých volání uživatelského rozhraní. Vyjadřuje kroky testu na úrovni blíže vašemu uvažování a pravděpodobně blíže požadavkům, které máte. A za druhé, chráníte se před budoucími změnami v uživatelském rozhraní. Takže se nebojíte změn.

Krok 4: Refaktor

Není to vše, co má za následek; je to jen udržování věcí snadno čitelných. Ale testovací kód nejvíce.

Jakmile napíšete svůj první test, zkuste si je přečíst. Pokuste se uhádnout, jaký je jejich záměr a co se snaží dosáhnout. Dobrý test by měl být čitelný jako próza. Experimentujte, vytvářejte pomocné funkce, artefakty, cokoli potřebujete, ale udělejte to čitelné. V budoucnu ji budete muset přečíst a porozumět jí.

Není třeba říkat, že testovací kód by měl být čistší a srozumitelnější než výrobní kód.

Krok 5: Nezapomeňte na obchodní hodnotu

Pokud budete postupovat podle kroku 2 (měli byste), všimnete si, že jsme nakonec vytvořili spoustu testů pro mnoho malých věcí.

Když testujete věci ručně, ne všechno, co testujete, je to, co jste požádali o implementaci; k dosažení tohoto cíle podnikáme mnoho malých kroků. A protože je testujete ručně, nedává vám žádný význam, protože jakýkoli ruční test, který provedete, bude po dokončení zničen. Je to věc mluvení; nezničíme to; prostě to neopakujeme.

Když opakujeme stejné kroky s automatickým testováním, nakonec skončíme se spoustou testů. Jakmile napíšeme test, zůstane zde, pokud jej neodstraníme. To je v pořádku. Říká se jim schodišťové testy. To znamená, že se jedná o testy, které fungují jako malé kroky, které nám umožňují dosáhnout našeho cíle. Jakmile dosáhneme svého cíle a máme několik užitečných testů, můžeme tyto staré testy odstranit. Nenechte se k nim velmi připoutat, děkujte mu a odstraňte je.

Jaký je náš cíl? Jedná se o implementaci některých funkcí. Musíme implementovat funkci, která dává obchodní hodnotu. Náš test musí ukázat, jaká je funkčnost a jak to funguje. Měli bychom být schopni to přečíst, pochopit a zapamatovat si to z našeho testu. Každý test by měl přímo odrážet obchodní hodnotu, kterou dává.

Další krok: Použijte tabulky

Téměř všechny testovací rámce přijímají tabulky. Jsou po ruce. Naučte se jejich API a používejte je.

Proč jsou tak po ruce? Protože když máte jeden kód, který testuje jeden případ, můžete přidat další případy přidáním řádků do tabulky. Pouze s jedním testovacím kódem můžete zpracovat desítky případů. Snadněji se udržují a čtou. Nepochybujte o tom, že váš test bude mít stejný počet tabulek, kolik bude mít smysl.

Závěr

Skvělé testování je jen otázkou introspekce. Naučte se, jak věci testujete ručně, proč postupujete podle některých kroků, a žádné jiné. Poté je automatizujte.

Nechte testovací kód pracovat za vás.