Jak psát kód: Testujte své změny
Školení, která pořádám 
Všechny změny, které provádíte, byste měli otestovat. Této chyby se často dopouští i mazáci, kteří si jsou celkem jisti tím, co kód dělá, jenom z jeho čtení. I jim se ale může stát, že něco přehlídnou.
Když píšete podmínku, tak ověřte situaci, kdy je i kdy není splněna. Když pracujete s polem, tak ověřte, co udělá prázdné pole. Pokud máte kód pokrytý testy, tak je to jedině dobře, jen ty testy samozřejmě nesmíte zapomenout spustit. Většinu změn byste ale i tak měli otestovat v kontextu celé aplikace. Třeba test netestuje přesně ty stejné podmínky, které nastávají v aplikaci.
Pokud je těžké změnu otestovat v kontextu (třeba proto, že opravujete chybu projevující se za podmínek, které nedokážete navodit), tak byste ji měli otestovat aspoň v izolaci. Třeba aspoň tak, že kousek měněného kódu vezmete a spustíte ho z příkazového řádku.
Důležité je si postup co nejvíc zautomatizovat. Syntaktickou analýzu (php -l) spouštějte v pre-commit hooku. Pokud máte více kontrol, které jsou rychlé a nemají false positives, tak je tam dejte všechny. Může to být nástroj na kontrolu neinicializovaných proměnných nebo třeba konzervativně nastavený JSHint. V editoru si nastavte klávesovou zkratku, která spustí testy.
Mně osobně a spoustě dalších vývojářů také pomáhá napsání provedených testů do commit message. Často stačí napsat jen “Ran unit tests” nebo “New unit tests”, ale někdy je potřeba se zamyslet trochu víc. Několikrát se mi stalo, že jsem kód chtěl už už odevzdat, ale při psaní testovací zprávy jsem se zamyslel nejen nad tím, jak jsem kód už otestoval, ale také jaký by byl na jeho otestování nejlepší způsob. Na základě toho kód pak třeba ještě změním.
Změny je potřeba otestovat také po mergi, ať už v něm jsou konflikty nebo ne. Možná někdo řešil stejný problém jako vy a než stihnete svou změnu pushnout, tak přidal stejně pojmenovanou metodu na jiné místo.
Zkrátka ověřujte všechny změny, i ty, které vypadají naprosto neškodně.
Diskuse
cabadaj:
Nám se ve firmě osvědčil postup:* vývojář A napíše kód
* vývojář A napíše smoke test
* vývojář B zkontroluje kód (koukne jestli bylo zvoleno dobré řešení problému)
* vývojář B rozšíří testy
* vývojář C zkontroluje testy
Tento postup má několik výhod:
* vývojář B není zatížen vymýšlením základní kostry testů (jak je mockovat, ...) a může se více soustředit na veškeré okrajové situace, které testovat
* každý kód vidí dva lidé
* vývojář A není nucen testovat vlastní kód (buď by jej nemusel napsat dobře nebo by byl nucen k pokusu o rozbíjení vlastního kódu a to je mentálně náročné)
Visitor:
<i>* vývojář B zkontroluje kód (koukne jestli bylo zvoleno dobré řešení problému)</i>U nás před programováním si raději domluvíme jak se to bude programovat (design aplikace). Než aby mi následně programátor C řekl, že to je koncepčně špatně. ;-)
Michal Raška:
Jakube u testů jsem narazil na jednu záludnost v případě, že testy i aplikaci člověk píše sám.Netýkalo se to sice PHP, ale myslím, že je to obecné. Pokud píši kód, tak nějak vnitřně a potom i analýzou si stanovím vstupy a možné stavy a reakce na ně. Potud dobrý, ale klíčový problém nastane, když člověka některé možnosti vůbec nenapadnou, nebo nejsou známé a tak nejsou ošetřeny ani v kódu a ani v testech. Samozřejmě se jedná o složitější kód.
Osobní zkušenost.
Nik:
Aneb důvěřuj, ale prověřuj. A to se mi spousta lidí smálo, že si ověřuji každou úpravu, že to prý zdržuje (=nikdy jsem nepozoroval).... a ikdyby, tak hodinu ladit nějaký překlep je asi efektivnější :-)
Diskuse je zrušena z důvodu spamu.
© 2005-2024 