34 komentářů k článku Testování a tvorba testovatelného kódu v PHP:

  1. 5o

    Re: Testování a tvorba testovatelného kódu v PHP

    Zacina sa to dobre, konecne nieco poriadne pre PHPckarov na zdrojaku.

    1. anonym

      Re: Testování a tvorba testovatelného kódu v PHP

      také to ve mne vzbudilo naděje: testování uznávám jako přínosné, ale vždy se najde spousta věcí, u kterých si neumím testy vůbec představit. Doufám, že mne tenhle seriál dokope se na to konečně vrhnout a v nějakém projektu vyzkoušet.

  2. Tharos

    Díky za článek

    Díky za fajn článek a přeji hodně vytrvalosti do dalších dílů. Neodpustím si jedinou oponenturu, a to k tvrzení:

    „A tím nemyslím jen fakt, že veškeré chyby jsou objeveny a opraveny včas, často ještě před prezentací produktu zákazníkovi.“

    To, že díky psaní testů budou veškeré chyby objeveny a opraveny včas, je IMHO utopie. :)

    1. Aleš Roubíček

      Re: Díky za článek

      Souhlas. Hlavně úplně špatná motivace a nesmysl.

      Testy píšeme proto, abychom byli co nejrychleji informováni o tom, že se rozbilo/ něco, co před tím možná fungovalo. Nebo že to funguje jinak než test očekává. Pokud píšeme testy napřed (TDD), je možné, že náš kód bude jednodušší a tím se může snížit i výskyt chyb.

      1. Michal

        Re: Díky za článek

        Je hodne duvodu proc. Ja treba pisu testy protoze jsem linej.
        Dokud se web musi rucne proklikavat aby se zjistilo, jestli „ten posledni update nerozbil zase ten form co posledne“, neni u me hotovo.

        Behem 2. mesice na projektu uz se testy brutalne vraci v case a hlavne energii.
        Proklikavani a hledani chyb manualne je jednou z nevjvice vycerpavajicich praci na projektu a denni energie kazdeho programatora neni nevycerpatelna.

        Mimoto se mi uz stalo ze me testy odhalili spoustu chyb, ktere jsem nemel sanci odhalit a 100% by na produkci prolezli.
        Neni nad to upgradnout php, spustit testy a vedet, ze ho muzu s klidem upgradnout na produ.

    1. j3nda

      Re: Howad

      nekdy je vhodne pristupovat k prvku primo, jak ukazuje priklad. zde je z pohledu optimalizace spatne jenom to count(), tj.


      --for ($i = 1, $maxi=count($va­lues); $i < $maxi; $i++) {
      ++for ($i = 0, $maxi=count($va­lues); $i < $maxi; $i++) {

    2. hromadadan

      Re: Howad

      Ty blbečku blbá, tohle není článek o cyklech, ale o testech.. „.. mam chut vrazdit“ – silná slova uhrovitého zrzka za poprskanou klávesnicí, že?

      1. Michal

        Re: Howad

        Myslim ze oba byste tech pocitacu meli nechat a jit delat treba myslivce, tam je clovek na vzduchu a vycisti si hlavu ;-)

        1. failer

          Re: Howad

          Ehm. Duvod pro Foreach je schopnost paralelniho behu (pracuje s kopiemi tabulek). Duvod pro bezny For je zajisteni posloupnosti v poli.

  3. Clary

    Dodatek

    Ještě bych zmínil, že chyba nemusí být zavlečena nepozorností, ale že prostě v programu uděláme úpravu, která nějakým způsobem ovlivní chování kódu, který napsal kolega. Setkal jsem se s názorem, že k potlačení chyb stačí u psaní přemýšlet a udržet kód v hlavě, ale při psaní projektu v týmu je toto zhola nemožné.

    1. Michal

      Re: Dodatek

      To o tom premysleni a udržování kódu v hlavě mi pripomnelo pribeh jednoho Ostravskeho tramvajaka, kterej zapomnel pred jednokolejkou vzit mobil a zavolat tramvajakovi co mel jet proti nemu – a taky tam jel ;-) . Lidskej faktor uderi vzdy kdyz to nejmene cekas.

  4. yad

    Testy by mali byť krátke...

    Udržať tesy krátke nie je zasa také ľahké, ak to robí komplexné veci. Napríklad mne sa už podarilo na funkciu s 4 riadkami napísať test o cca. 60 riadkoch a to je celkom stručný a jasný.

    Ale súhlasím s tým, že na triviálne operácie držať testy krátke je nutnosť.

    1. arron

      Re: Testy by mali byť krátke...

      Pak je ale otázka, jestli není ta funkce špatně napsaná a nedělá víc věcí než jednu ;-)

      1. yad

        Re: Testy by mali byť krátke...

        Vytvára dotaz na traverzný strom a využíva pri tom ORM. Ale jedná sa o Python, kde ORM frameworky (Django ORM, SQLAlchemy atď. umožňujú zaujímavejšie veci).

        1. arron

          Re: Testy by mali byť krátke...

          Ta otázka byla spíše řečnická ;-) Ono se to takhle z popisu stejně nedá říct, to už je potřeba pak vidět kód :-) Taky mám pár testů, které se trochu rozlezly, ale je to tím, že je potřeba připravit nějakou složitější vstupní strukturu dat na které se pak něco provede…

      1. yad

        Re: Testy by mali byť krátke...

        Je tam subquery a join. Takže sa testuje 5 prípadov – join (2x), subquery+join (3x). Je tam 5 položiek v traverznom strome (čo teraz pozerám) a na každú sa testuje členstvo.

        Jedná sa query, ktorá pýta cestu hore pre traverzný strom plus s najbližšími uzlami.

        1. Aleš Roubíček

          Re: Testy by mali byť krátke...

          Sám píšete, že v tom „testu“ je testů hned několik. #testsmell

  5. Paja

    pridal bych bod 6 do sekce vymluv

    Vyrobim si vlastni err_handler ktery mi vsechny chyby loguje v prehledne forme do databaze a mam i pekny prohlizec tohoto logu.
    Loguju vcetne zformatovaneho vypisu debug_backtrace, parametru na vstupu scriptu, to abych vedel co chybe predchazelo.
    V programu volam na ruznych mistech trigger_error. Vzdy kdyz nastane neocekavane. Napr. od spoda – v databazovem rozhrani:
    if (pg_last_error($this->dbresource)) {
    trigger_error(„DB error : „.pg_last_error($this->dbresource).“n$qu­ery“, E_USER_WARNING);
    return false;
    }
    Ale i jinde – napr. pokud cekam, ze dotaz nutne musi vratit nejaka data a on je nevrati :
    if (!$data=$db->get($sql)) {
    trigger_error(„ne­muzu nacist podrobnosti o baleni toaletniho papiru s id: $this->id“, E_USER_WARNING);
    }
    A jsem na nervy, pokud mam cokoliv v errorlogu a jdu patrat jak k tomu mohlo k… dojit.

    Poznamka: (asi se budu v diskuzich opakovat). Vyrobte objekt v PHP, ktery vyrabi desitky SQL dotazu (pokud mate framework ktery tohle miluje) a mate co testovat. Nebo udelejte view, resp. SQL funkci, ktere vam daji data. Pak se kouknete pri zmenach v databazi, co tohle view dava za data. Na prvni pohled vidite, jestli to view funguje nebo ne. Muzete si na nej napsat i test (nejlepe opet view).
    Poznamka_2: PHP nebyl stvoren pro aplikace, ale pro zobrazeni dat. A data se najdou v databazi. Uz jen ten rozdil, ze PHP se vykona cele znovu pri libovolnem kliknuti do aplikace a zacina s cistym stitem. To uz i v perlu bylo fastcgi, ktere je perzistentni (urychleni objektu v PHP se resi cache vseho mozneho, coz jen prinese dalsi nejistou).
    Poznamka_2.5: netusim, jak otestovat ze vysledek PHP sccriptu, vypada stejne v ruznych prohlizecich.
    Poznamka_3: i ja pisu chyby. Vic nez je mi mile. Priklad z dneska: pri implementaci „do ruky“ a „na postu“ jsem si nevsimnul, ze generator mailu zakaznikum, aby mohli sledovat cestu baliku, rozlisuje postu a PPL podle prvnich znaku cisla baliku (drive BO, dnes DR a NP). A chybou se pro DR a NP generoval v mailu link na PPL. Tri tydny trvalo, nez si nejaky zakaznik tohodle vsimnul. Fakt nevim jak na toto napsat test. Rad bych si nechal poradit.
    Poznamka_4 (nijak se nevztahujici k testovani, spise jen povzdech nad projekty kde je prilis mnoho tvurcu a jako zamysleni kam ten vyvoj speje): vcera jsem stravil 4 hodky s pomoci znamemu, ktery si sam udelal eshop nad presto. Problem 1: rozhodli se, ze z verze na verzi zmeni system tak, ze drive byl stav nove objednavky zavisly na stavu skladu. V nove verzi udelaji dva stavy. Prvni jen ulozi do historie objednavky a stav nove objednavky pridaji jako dalsi stav v historii a to na konstantni hodnotu. Dalsi problem byl v nepochopeni, ze uzivatel presta potrebuje, aby se mu pri naskladneni zbozi samy oznacily objednavky, ktere muze vydat. Spojeni toho, ze stav objednavky neni soucasti vlastni objednavky, ale je potreba ho najit v historii jako posledni stav, a mysql ktere neumoznuje joinovat subquery ve view zpusobilo vygenerovani asi 6-ti vnorenych view, ktere dalo ve vysledku: objednavce x nastav novy stav na y. Coz pak zabralo 6-ti radkovy patch do sekce prijmu zbozi v PHP. Fakt jsem byl z toho presta zdeseny, jak je to uzasne modularni system, ktery umi vse.

  6. enumag

    Žádost o vysvětlení

    Mohl by mi autor vysvětlit tento výrok?

    „Čím více času investujete do psaní testů, tím méně potom budete potřebovat na refaktoring, který si vyžádá nějaká změna.“

    Když něco refaktoruju, tak to zpravidla znamená změnu API. A když změním API, musím změnit i volání v příslušných testech, tedy na refaktoring potřebuji naopak VÍCE času než kdybych testy nepoužíval. — Budu rád když mi to někdo vyvrátí. ;-)

    1. 5o

      Re: Žádost o vysvětlení

      Tak toto je jednoduché, ak píšeš aplikáciu iba pre seba tak to je pravda. Ale predstav si napr. niektorý framework alebo plugin/modul bez testov a urobia refaktoring niektorej metódy (verejné API sa nemusí nevyhnutne zmeniť). Ako si bez testov môžeš byť istý, že si nevydal spätne nekompatibilnú verziu príp. s bugom, ktorý je už niekde v issue trackery.

      1. enumag

        Re: Žádost o vysvětlení

        Ano, to mi došlo také. Pod refaktoringem si ale představuji spíše rozsáhlé změny které většinou znamenají i určitou změnu API (popřípadě úplně nové API). U mne jsou tyto případy mnohem častější než refaktoring bez změny API. Takže jsem měl vlastně také pravdu (bohužel) a testy mi to v těchto případech zkomplikují.

        Na druhou stranu je fakt že díky TTD by kód mohl být od začátku lepší a podobný refaktoring by neměl být potřeba nijak často.

        1. arron

          Re: Žádost o vysvětlení

          Autor tím chtěl IMHO říct to, že když máš testy a změníš cokoliv v aplikaci, tak Ti testy ušetří práci v tom, že poměrně rychle (a automaticky) zjistíš, jestli se někde něco nerozbilo. A to něco vůbec nemusí přímo souviset s tím, co se změnilo.

          Refaktoring je naopak potřeba skoro pořád. Nikdy se nic nepovede napsat ideálně napoprvé a kód je potřeba průběžně udržovat. Já třeba zpravidla zjistím, že nějaká metoda je potřeba ještě rozdělit a nebo že některá funkčnost bude vhodnější vyčlenit do samostatného objektu. Ačkoliv tedy neměním funkčnost, tak mi testy pomůžou v tom, že vím, že to pořád všechno funguje správně.

          No a v Tvém případě víš, že změna API Ti nezbourala úplně druhý konec aplikace. A ano, to se běžně stává :-)

          1. Clary

            Re: Žádost o vysvětlení

            Nelze než souhlasit. Většina knih co se zabývá refaktorováním je z první poloviny o tom jakým způsobem nacpat hnusný špatně testovatelný kód do testů, aby následně bylo možno refaktorovat (tj. přepsat na čistší kód bez změny funkčnosti aplikace).

        2. 5o

          Re: Žádost o vysvětlení

          Je rozdiel medzi prototypovaním a písaním znovupoužitelnej jednotky. Pri portotypovaní sú testy zbytočné. Potom, keď som spokojný s API začnem písať testy a následne kód refaktorujem, čiže API je zmrznuté, ide čisto iba o vylepšenie kódu. A keď sa jednotka osvedčí a je treba ju prepísať, napr. kóli novému frameworku, napíšem prvý test a na to triedu. Keď viem čo chcem je písanie testov hračka.

        3. jos

          Re: Žádost o vysvětlení

          „Takže jsem měl vlastně také pravdu (bohužel) a testy mi to v těchto případech zkomplikují.“

          neměl, sorry, ale vůbec nevíš o čem testování je, což neví nikdo dokud to nezkusí ve velkým

          1. enumag

            Re: Žádost o vysvětlení

            V tom že nevím o čem je testování máš rozhodně pravdu. :-) Proto se to snažím naučit.

      2. jos

        Re: Žádost o vysvětlení

        „Tak toto je jednoduché, ak píšeš aplikáciu iba pre seba tak to je pravda.“

        ehm, když po dvou letech přídeš k aplikaci kterou sis napsal „iba pre seba“, tak ty testy oceníš taky

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3693