Názory k článku
Testování není nástroj, ale metoda vývoje

Nechystá se článek o tom, jak s testováním v PHP začít? Mám zkušenosti s testováním v Javě (JUnit), ale v PHP mi to vždycky přijde dost složité.
Myšlenkově se vždycky zastavím na nějakém problému (např. jak v Nette testovat správnou odezvu presenteru? tím jaké proměnné předá šabloně? něčím jiným?) a do praxe už to neuvedu.

Zkus se mrknout sem: http://wiki.nettephp.com/cs/tutorialy/navstevni-kniha-v-nette-s-testy-tdd

Mně osobně se sice z nějakého iracinálního důvodu také příči psát testy před produkčním kódem, ale to úvodní napsání testu a jeho spuštění má svůj význam. Je to vlastně „otestování testu“ – správný výsledek je, že musí selhat. Zmenší se tím riziko, že v testu je chyba, která dává falešný pozitivní výsledek.

Hele, to je hodně zajímavá myšlenka ^^. Asi to bude důvod, proč je začnu psát před produkčním kódem :3.

pokud nemate pevne dane API, ktere mate naimplementovat, tak vytvoreni testu vam pomuze si ohledne toho API ledacos ujasnit.

Taky jsem chtel pripsat, ze pouziti vasich trid v testu vlastne vytribi API. Napr. si clovek uvedomi, ze musi predat nejake dalsi infórmace zvenku.

Jn, taky hezká pointa. Tohle by jsme se měli taky učit ve škole, takto se k tomu dostanou lidi až v praxi až se spálí (pokud nebudou mít štěstí na dobrého team leadra) nebo pokud se o programování zajímají aktivně.
Jakože dělali jsme nějaké drobné JUnit testy, ale osobně si myslím, že tomu byla přiložena minimální váha až už vůbec nebyly zmíněny tyto výhody…

Psaní testů před produkčním kódem získává smysl ve chvíli, kdy si chcete ověřovat, že se vůbec test spustí, případně, že je napsaný správně. Např.:

public function tesFooBar() {
  //kód testu
} 

PHPUnit vám dál vesele vykresluje tečky a myslíte si, že tento test prošel, ale on se vůbec nespouští. Na to je to dobrá kontrola.

Osobně mám problém s tím, že když napíšu test před produkčním kódem, tak leckdy namísto stručného F dostanu obří PHP error (ta třída, kterou testuji, nemusí ani existovat), celý výpis se znepřehlední a musím jej sáhodlouze zkoumat namísto rychlého zhlédnutí. To mě demotivuje.

ano, návrh PHPUnit není moc dobrej, je na čase (pro odbourání demotivace) začít používat něco jinýho (http://www.testilence.org/)

test:

class whateverTest
extends Tence_TestCase
{
    public function testOK()
    {
        return $this->assertTrue(true);
    }
    public function testFailure()
    {
        return $this->assertTrue(false);
    }
    public function testMalformed()
    {
    }
}

spuštění testu

$ make check SUITE=whateverTest
cd tests && \
  tence -I "$PWD/..:$PWD/../.." -r alltests.php whateverTest
.FM
whateverTest::testFailure
 AssertEquals expected boolean(True) got boolean(False)
whateverTest::testMalformed
 bad test return value: type NULL, value NULL

3 run, 1 failed, 0 threw, 1 malformed
make: *** [check] Error 5

sorry za to formátování, v náhledu nevidim že by fungoval tag code, tak sem to dal do pre

Ad „na výhody ovšem narazíte při prvním refaktoringu, kdy si nevědomky rozbijete zpětnou kompatibilitu a půlka testů vám zčervená. Z důvodů, které by vás nenapadly.“

Nic proti testování, ale v první řadě je potřeba navrhovat strukturu systému tak, aby k takovým situacím nedocházelo – nesmí to být černá skříňka, která si dělá co chce, změna jednoho modulu/metody ovlivní celý systém atd. I složité systémy lze strukturovat tak, aby byly přehledné – aby to nebylo klubko zamotaných „špaget“, kde všechno souvisí se vším. Takže doporučuji navrhovat systém tak, abychom se v něm vyznali a aby nám nespadl na hlavu, i kdybychom žádné testy neměli. Testy nám potom dodají jistotu a dodatečnou kontrolu (což samozřejmě neznamená, že je nemůžeme napsat před samotným funkčním kódem, ale píšeme je po analýze, návrhu).

Ad „Jsem toho názoru, že kód nepokrytý testy je bezcenný.“

Příliš silná slova. Všechno je o penězích a vážení rizika. S rostoucími investicemi do testování zvyšujeme kvalitu kódu, ale efektivita každé další koruny investované do testování se postupně snižuje. V první fázi investujeme do testování trochu času (peněz) a odhalíme zásadní chyby, které by vedli k neakceptaci programu nebo drahému selhání, další investicí do testování objevíme nějaké kosmetické chyby, což se asi taky vyplatí… testovat můžeme dál a dál, do aleluja, ale už z toho nic nebude – budeme objevovat banální chyby, které za tu námahu (čas/peníze za testování) nestojí – daleko ekonomičtější je je tam nechat a opravit je za chodu nebo v další iteraci. Jejich testování by znamenalo vyšší náklady než výnosy (snížené riziko/ztrátu). Kód nepokrytý testy tedy není bezcenný – pokud za něj zákazník zaplatí, cenu má, a pokud bude fungovat.

Ad „Bez testů by ověřování funkčnosti trvalo několik minut (pokaždé) a musel by ho provádět člověk, jehož práce stojí peníze“

Autor neslyšel o automatizovaných testech funkčnosti? Ty jsou snad ještě důležitější než jednotkové testy, protože kontrolují funkčnost programu z pohledu uživatele – komplexně – ne jen jestli nějaké malé kousíčky uvnitř fungují správně (to je předpoklad nutný, ale ne dostačující).

Ad „potřebujete zjistit, zdali jste např. refaktoringem modelu nevyřadili z provozu některé sekce webu.“

Zde se hodí silně typované statické jazyky – ne že by u nich testy nebyly potřeba, ale jejich význam není tak velký.

Ad „Testy mohou být zajímavé i pro projektového manažera, který podle nich může rychle zjišťovat, co tým udělal – co není otestované, tak ho nezajímá, protože to nemusí fungovat.“

Projekťák nepozná, jestli ty testy jsou správně napsané, nebo jestli to jsou jen jako-testy, aby tam byly zelené fajfky a všichni byli spokojení.

…Autor neslyšel o automatizovaných testech funkčnosti? Ty jsou snad ještě důležitější než jednotkové testy, protože kontrolují funkčnost programu z pohledu uživatele…

Mno a není to v zásadě to stejné? Nezáleží na tom jestli je na prvním místě PHPunit nebo Selenium důležité je, aby byly testy při vývoji webů samozřejmostí (což nyní neplatí :-().

RE: odstavecek o snizujicim se vyznamu testu v case, hlavne veta „daleko ekonomičtější je je tam nechat a opravit je za chodu nebo v další iteraci“.:
S tim si dovolim nesouhlasit, testy maji stejny vyznam po celou dobu existence projektu – pravda, ze zacatku jejich vyznam spociva spise v overovani vyvoje, ale postupne je velka sada testu pomalu jedinym moznym zdrojem informace, jestli jsme svoji byt malou zmenou „neco nerozbili“. A pokud je pro nas kriticky dulezite „nic nerozbit“ a presto pokracovat ve vyvoji, pak automaticke testy dramaticky nabyvaji na dulezitosti. A k vete „daleko ekonomičtější je je tam nechat a opravit je za chodu nebo v další iteraci“ – vim, ze nasl. priklad je trochu prehnany, ale predstavte si, ze vyvyjite software pro letadla a diky male chybce to letadlo spadne a vsichni zahynou. Lidi na palube toho letadla asi nebude moc zajimat, ze tu chybu v dalsi iteraci opravite :).
Po nekolika letech vyvoje naseho projektu jsem nedavno diky automatickym testum objevil chyby, ktere se rozhodne nedaji oznacit za banalni a kdyby se projevily u zakaznika, byl by to p..ser. A byly tam jenom proto, ze projekt uz je priliz velky na to, abychom ho dokonale udrzeli v hlavach a domysleli vsechny scenare…

Zkusím to vysvětlit jinak… Existuje dokonalý software?

…neexistuje – každý software má chyby, vždycky je co vylepšovat, jsme jenom lidé. Cílem řízení kvality (něco víc než testování) není dotáhnout ten software k dokonalosti, snížit počet chyb na nulu, ale dotáhnout ten software do přijatelné kvality za přijatelnou cenu. Tzn. aby letadla nepadala (to je nepřijatelné), ale zároveň aby vývoj nestál miliardy a netrval desítky let (což je rovněž nepřijatelné). Proto je správné některé drobné* chyby (nedokonalosti) v programu nechat a neztrácet s nimi čas (ani s jejich testováním) a opravit je buď později nebo až je bude někdo potřebovat vyřešit.

*) drobná chyba je taková, která nezpůsobuje škody typu pád letadla, smrt lidí, finanční ztráty… nezpůsobuje škody prakticky žádné, akorát může způsobit třeba trochu nepohodlí při používání programu – v malém procentu případů atd.

Dovoluji si oponovat: Souhlasím s názorem z knihy Programátor pragmatik – Opravujte rozbitá okna. Najdete-li někde něco rozbitého, nedodělaného, opravte to hned. Jinak se vám to nakupí. Ona i malá chybka, která jen způsobí nepohodlí uživatele, může skrývat něco hlubšíh.

Jestli sledujete Minuty před katastrofou, tak se při každe havárii sejde několik drobností, opoměnutí, nedorozumění, nepochopení a předpokladů a vede to k chybě.

Proto třeba tento týden budu prověřovat rodné číslo v našem systému (viz http://www.aspectworks.com/cs/blog/2010/05/generator-rodnych-cisel/ a odkazy z článku).

Zajimalo by me jestli ma cenu a pripadne jak testovat rozhrani? Ma vubec cenu ho testovat, kdyz si udelam MOCK rozhrani a pak nastavim na metodu->will($this->returnValue(…)) a otestuji vracenou metodu.

Samotné interface je zbytečné testovat … ani není co, ale ke každému rozhraní se váže nějaký kontrakt, který „musí“ plnit každý implementátor rozhraní. No a tento kontrakt lze otestovat. Takováto sada testů se pak může pustit na každého implementátora.

Testovat má cenu pouze výkonný kód. Rozhraní je jen předpis. Stejně tak je zcela zbytečné testovat vlastnosti objektu (settery a gettery). Mock objekty jsou dobré pouze pro testování objektu v izolaci. Testování mock objektu samotného je opět zbytečnost. Proč testovat něco, co nepřináší žádný užitek?

Vždyť při samotném psaní produkčního kódu určitě testujete, jen takové testy nemají stálý charakter. Dumpujete si proměnné, zkoušíte na nějakém dočasném kódu (třeba ve funkci main() nebo v controlleru), jestli daná třída dělá to, co má. Jednotkové testy zavádějí stálost. Na jedno kliknutí prověříte funkčnost všeho dosavadního kódu.

S tímhle mám velký problém, ty první testy samozřejmě dělám, jednotkové ne. Tou stálostí se ale rozumí spíš dokumentovanost. Dočasný kód člověk neukládá, takže jím nemůže argumentovat. Bohužel se unit testy budu muset naučit, protože bez nich to dnes „nejde“ – i když drtivá většina těchto testů předváděná v různých tutorialech kontroluje úplné triviality, které jsou stejně jasné z kódu :-(((

tohle píšu z pozice PHP programátora

až ti testování úplných trivialit ušetří spoustu času (takže zachrání termín) při hledání překlepů (protože s unittestama překlepy neexistují) nebo umožní dělat brutální refaktoringy bez refreshování desítek tabů v prohlížeči, tak unittestování teprve doceníš

přístup typu

cože? to mam testovat že mi metoda sečte dvě čísla?

se pak rychle obrátí v přístup

cože? na tenhle kód nejsou testy, když tomu nic nebrání?

nechci vypadat jako nejakej über ignorant, ale me se to stejne stale zda takove… „prapodivne“. uz sem si nekolikrat pohraval s myslenkou, ze ty testy udelam ;) , ale stale se k tomu nemuzu dokopat.
ono je to pekne podivat se tady na par tutorialu (viz clanek k Nette), ale testovat jestli mam v databazi 2 zaznamy mi prijde naprosto k nicemu – dulezite je snad co to je zac, k cemu se to vztahuje, jestli jsou spravne vlozene data* a podobne. napsani takovych testu by pak skutecne znamenalo stravit jejich psanim delsi cas, nez psanim samotne aplikace.

* nedavno jsem narazil na jakousi „chybu“ TinyMCE – nekolik hodin sem koukal do zdrojaku, kde se mi ztraci hodnota z formulare. nakonec jsem zkusil vypnout TinyMCE – ktere je samozrejme az na frontendu uzivatele – a voala, cely problem zpusobovalo prave to, ze z nejakeho duvodu ve vsech formularich aplikace, az na tento jeden, TinyMCE nepredal svuj obsah zpet textovemu poli. jak testovat takovehle veci? (tedy – proc delat unit testy, kdyz pak stejne musi prijit tester a cele to ozkouset)

test kterej leze do databáze není unit test (Beck, TDD by Example)

testování kooperace browseru s aplikací pak už ani náhodou (takový testy samozřejmě nezavrhuju, ale to je jiná hra na jiným hřišti, v jiný lize)

na pár tutoriálů se vykašli, přečti si toho Becka, a až budeš vědět co je TDD a napíšeš si pár testů*, tak tě to über ignorantství přejde

*) v tvým případě by to chtělo testovat: když mi přilezou správně data, pokusí se je aplikace správně nacpat do databáze? potom při úvahách kde se stala chyba můžeš na základě testů vyloučit některý místa, kde se to „taky mohlo podělat“, ale nepodělalo, protože testy procházejí

Predstavte si, ze delate ve stare technologii a musite testovat rucickama. TO me vzdycky s..tvalo. a nehnu s tim

radikální řešení: najdi si jinou práci (teda jinde)

Pracuje se na tom, ale hochu, ja nejsem v Praze

A máš možnost kód krokovat, zadat break-points a vypsat stav proměnných?