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

  1. pav

    testování jen veřejných tříd
    Hezký článek, nutí to k zamyšlení.

    Přesto se cítím nejistě u tvrzení, že se testují jen veřejné třídy. Protože často separuji do privátních metod část kódu jen za účelem lepší čitelnosti kódu. Přesto by mohly být tyto metody testovány nějakým jednotkovým testem.

    Vyumělkovaný příklad: potřebuji ve veřejné metodě provést součet nějakého pole (pomiňme existenci php funkcí) a tento kód dám do privátní metody, abych udržel čitelnost té veřejné. Neopakuje se, neliší se, prostě jen pro čitelnost. Nedává mi smysl „separovat odpovědnost“ pro něco takového do vlastní třídy. Ale proč to netestovat?

    1. Podbi

      Re: testování jen veřejných tříd
      Vždycky je možnost otestovat veřejnou metodu, která provede i volání vnitřní privátní metody, která je tedy v tomto ohledu testy pokryta.
      Já osobně v případech, kdy cítím potřebu otestovat nějakou privátní metodu nutně samostatně sáhnu po Reflekcích…

    2. arron

      Re: testování jen veřejných tříd
      Jsou případy, kdy se to opravdu hodí a pak je docela prima si pro takové věci dopsat podporu do nějaké testovací knihovny. Na druhou stranu, ke všem protected a private metodám se nutně musí být možné dostat přes některou z public metod. To znamená, že pokud se dobře otestují všechny usecase, tak by měly být otestované i všechny protected a private metody. No a pokud nejsou, tak pravděpodobně obsahují kód, který je možné odstranit, protože se nevolá :-)

      1. Jan Machala

        Re: testování jen veřejných tříd
        Ano jde to, ale většinou se počet průchodů tou veřejnou metodou tak, abych pokryl všechny (mezní) případy té volané privátní, znásobí. A tím i dost naboptná test :-(

        1. arron

          Re: testování jen veřejných tříd
          Jo, testy dokážou nabobtnat nehorázným způsobem :-) Ale je pravda, že na jednoduchý kód je jednoduchý test a na složitý kód je řádově složitější test. Takže když test opravdu nabobtná, je na čase se zamyslet nad tím, jestli příslušný kód není příliš složitý a nestálo by za to ho nějak zjednodušit/rozdělit. Já osobně vždycky přijdu na to, že to jde a že je to tak správně :-)

    3. Martin Mystik Jonáš

      Re: testování jen veřejných tříd
      Privátní metody jsou privátní proto, aby o nich okolní kód – ať už provozní nebo testy nevěděly. Hlavní motivace je aby se daly snadno změnit bez nutnosti měnit další kód. Aby se změny v kódu zbytečně nešířily do dalších částí. Unit testy by jednotky (třídy) měly testovat z vnějšího pohledu – tetovat chování jejich rozhraní. Neměla by se podrobně testovat jejich vnitřní struktura.

      Ostatně testy píšeme primárně proto abychom mohli vnitřní strukturu měnit a něco (testy) nám hlídalo, že jsme přitom nerozbili něco ve vnějším rozhraní.

  2. honza

    Díky za zajímavé pokračování seriálu. Mně osobně také nepřijde optimální vůbec netestovat privátní metody. Navrhovaný postup „otestovat veřejné, které ty privátní volají“ mi připadá, že popírá princip unit testů, protože když to dovedu do extrému, tak bych mohl prostě spustit celý program a říct „ok, funguje, takže ty funkce co jsou uvnitř také fungují“.

    Btw – nový systém diskuzí na Zdrojáku je evidnentně hardcore – nevyplním mail, dostanu se na stránku kde je „chyba“ a nic víc – absolutně žádný způsob řešení, například odkaz zpět na diskuzi abych nemusel celý příspěvek psát znovu, nic. Co se děje? WordPress z roku 1998?

    1. Martin Hassman

      Re:
      Reaguji na ty komentáře, ta část ještě není dokončená, víme o tom a dostaneme se k tomu časem.

    2. arron

      Re:
      Jo, na tohle jsou různé názory napříč celou php komunitou. Někteří berou jako unit celou třídu (a pak dává smysl testovat jednotlivé usecase třídy, čili public metody), někteří berou jako unit jenom jednu funkci (a pak se testování neveřejných metod v podstatě samo nabízí). Záleží na konkrétním případu, co se hodí a co už ne. Obecně jsem zatím došel k tomu, že pokud se opravdu respektuje SRP, tak jsou třídy tak krátké, že neveřejné metody není potřeba testovat :-)

    3. BoneFlute

      Re: testování privátních metod
      Jednotkové testy testují třídu a její metody. A z pohledu testů privátní metody vůbec neexistují.

  3. Clary

    Testování soukromých metod
    Pročetl jsem zdejší komentáře a v podstatě všechny jsou pravdivé a zároveň nevyvracejí, co je napsáno v článku. Pokud mám ve třídě mnoho soukromých metod, velmi pravděpodobně porušuji SRP, pak je dobré třídu rozdělit. Samozřejmě i pak mohu mít ve třídě privátní metody, ale ty by již měly být natolik jednoduché, že je lze snadno otestovat při průchodu veřejné metody, která je využívá.
    Co se týče toho, že testujeme pouze rozhraní, je třeba si uvědomit, že rozhraním metody nejsou pouze její vstupy a výstupy ale i interakce s okolím – typicky když uvnitř metody pošlu SQL dotaz na databázový adaptér.
    V případě protected metody bych se pro testu nebál vytvoření potomka pouze pro účely, kde se protected změní na public. Tento postup je vlceku přijatelný, používají ho i největší kapacity na testování a refaktoring.

    1. arron

      Re: Testování soukromých metod
      To vytváření potomka je zcela „validní“ postup/přístup s jednou jedinou malou chybou…je to děsný opruz :-D Reflexe se z tohoto pohledu ukazuje jako daleko efektivnější, obzvlášť, pokud má oporu v nějakém testovacím frameworku (opora = nezajímá mě, že je to reflexe a nemusím na to moc myslet).

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=7018