Názory k článku
Začínáme s PHPUnitem - základní test

Aby se dibi kamarádilo s PHPUnitem, je potřeba zakazovat zálohování statických atributů (a možná i globálních proměnných). Objekty DibiConnection totiž vyhazují při pokusu o serializaci výjimku.

<reklamni-sdeleni>kdysi jsem o instalaci na Windows něco blognul http://www.vrtak-cz.net/instalace-phpunit-na-windows a taky udělal „screencast“ http://www.vrtak-cz.net/screencast-pear-phpunit.</reklamni-sdeleni>

Hezky clanek pro zacatecniky a lidi, co tvrdi, ze testy jsou ztrata casu. Jen nesouhlasim s tim, ze neni nutne psat testy pro settry.

Pro setery bych psal test jen pokud obsahuji nejakou (netrivialni) logiku. Dokud je to jedno prirazeni, tak neni duvod, jak je tam trebas podminka testujici korektnost parametru, tak uz si test zaslouzi. (Ty trivialni pripady stejne budou neprimo otestovany v testech jinych metod. A samozrejme je casto uplne nejlepsi psat imutable tridy, kde zadne setery nebudou.)

„A samozrejme je casto uplne nejlepsi psat imutable tridy, kde zadne setery
nebudou.“
1. Jak chcete v PHP zajistit neměnnost objektu?
2. Proč myslíte, že je to nejlepší? V jednovláknovém prostředí bez jakékoli konkurence. WTF?

1. Do PHP runtime moc nevidim, byla to obecna rada. Pokud se bude nekdo snazit, tak afaik nemennost v PHP znici, ale pokud je uzivatel vaseho API rozumny, tak porusovat kontrakt nebude.
2. Otazka dobreho stylu, konkurence je mozna nejvetsi argument pro, ale ne jediny. Pri imutabilite je napriklad zbytecne delat defenzivni kopie, nikdo vam nemuze poskodit data, ktera uz drzite.

Obecně nelze říct, že immutabilita je nejlepší nebo lepší než mutabilita. Jde to říct jen v konkrétních případech řešení nějakého problému.

S takovou formulaci bych souhlasil. S dodatkem, ze je lepsi nejdrive hledat imutabilni reseni a to opustit az pokud ma nejake vetsi nevyhody.

Hezky napsaný článek, ale začít integračním testem, to chce koule :)

Já vím, že kritizovat je mnohem snažší než napsat kvalitní článek o testování. Vlastně si myslím, že na to formát článku ani seriálu nestačí. Tady se opravdu vyplatí koupit si knihu nebo se nechat školit. Ale k věci.
Člověk by z napisu řekl, že když jdeo PHPUnit, tak v články budou nějaké jednotkové testy a ouha, máme tu test integrační (v postatě hlavně testujeme funkčnost dibi frameworku, nikoli našeho objektu).
Úkoly k praktickému cvičení jsou dost zavádějící. Přejdu to, že v ukázce někde používáš konstantu, jinde literál, a že vyhozuješ nevhodnou výjimku. :) Jak chceš prosím otestovat *„funkčnost třídy“*? Třída je pouze předpis, podle kterého se vytvářejí objekty, a ten zádnou funkčnost nemá.
„Napište test“ svádí zase k tomu, napsat jeden test, což jistě nestačí. Ano šlo by to udělat jednou testovací metodou, ale pak takový test nemá žádný význam, protože nám není schopný odhalit, co se vlastně stalo špatného. Víme jen, že něco selhalo, a to zjistíme i při spuštění skriptu na serveru. :)
K třetímu úkolu, správný jednotkový test nemá šahat na žádné IO. IO je totiž poamlé a nestabilní a tak nám nemůže zaručit opakovatelné výsledky, což je základní předpoklad pro dobrou test suite.

Přesně tak, zanedbaná terminologie v zájmu čtivosti ještě budiž, ale ty integrační testy jsou úlet.

Aleši, nemám teď bohužel dostatek času, abych odpověděl na všechno. Jen bych rád napsal jednu věc, totiž že se naprosto projevuje fakt, že ty prostě testovat umíš a jednoznačně nejsi cílovka článku.
Člověk, který o testování v životě slyšel jen minimum má jen mizivou představu. Já chci věci zjednodušovat, ne mu ještě naklást před oči další věci, jako je rozlišování mezi jednotkovým testem a integračním. Začátečník má přijít, nasimulovat správné použití metody v testu, test spustit a zatím se nestarat o nic víc (včetně toho, jestli to používá IO, jestli je zvyklý používat literály nebo konstanty). Samozřejmě, že cesta od tohoto bodu k plnohodnotnému testování není zrovna krátká, ale myslím si, že je dostatečně únosná i pro ty méně zkušené.

Já si myslím, že programátoři nejsou malé děti, abys musel zjednodušovat až tolik. Oni to jistě pochopí i když to bude napsaný krapet správnějš. Nejhorší návyky totiž programátoři získávaj na špatných ukázkách a výukových materiálech.

Aleši, řada vývojářů dodnes píše neobjektově, bez verzovacích systémů, s mizivou představou o tom, co jsou to návrhové vzory. Situaci jsem popsal před půl rokem tady: http://zdrojak.root.cz/clanky/mysql-v-roli-neschemove-databaze/nazory/6431/ Bohužel se toho k lepšímu moc nezměnilo (lépe řečeno nic). Nerad bych, aby to vypadalo, že programátoři jsou hloupí, ale já jsem za ty roky v praxi upustil od všech předsudků o tom, kdo co ví a co lze předpokládat. Ostatně se mi už pod ruce dostal i student informatiky na konci prvního ročníku, který nevěděl o existenci „if“. Programátor, který začne testovat, velmi brzo zjistí, že těch pár článků na zdrojáku mu dá jen první kopanec, ty návyky si musí buď někde načíst (což znamená stovky článků – sotva si někdo udělá návyky ze 3 článků na Zdrojáku), nebo získat od někoho zkušenějšího.

je to tak, i kdyz sem na php prisel z c++, kde sem pracoval s ryze objektovosti, zacinal sem s php ve firme, kde bylo vse proceduralni, a html zamichane v php, kdyz sem se zminil o tridach, tak sem byl konfrontovan s jednou tridou, a po tom co sem prohlasil ze v tomto pripade jde spis o simulaci jmeneho prostoru, protoze trida je opet proceduralni, nevyuziva dedicnosti, se mi dostalo jen nechapavych pohledu, a prazdnych vyrazu ve tvarich, a to vcetne velevazeneho pana inzenyra, cerstveho absolventa informatiky, ktery byl autorem te tridy. Za svou nekolika letou praxi v oboru sem byl konfrontovan se spoustou takvych projektu. Takze uz me to ani neprekvapuje. Cili ne jen ze se toho mnoho nezmenilo, ale ono se toho taky mnoho nezmeni. Lidi co jsou schopni myslet a pracovat objektove a na urovni je malo, a jsou v oborech s vyrazne vetsi financni vyteznosti, v php se budou stale pohybovat „zacatecnici“ kteri jednak svoji podhodnocenou a podprumernou praci srazeji ceny projektu na nesmyslne urovne a dlasich mraky fusheru, kteri napriklad umi trochu s photoshopem a nejake to php si taky splacnou.

Kupodivu na procedurálním kódu ve třídě není nic špatného. Spousta lidí píše třídy, aniž by vůbec dosáhli procedurální mety ,a to je pak hodně špatné.
BTW dědičnost není zrovna nejlepším argumentem pro OOP.

Pojem proceduralni sem pouzil proto abych se vyhnul zdlouhavemu popisu faktu, ze ona trida jmenujici se kosik, se starala o login/logou­t/registraci/sa­motnej kosik/objednav­ku/mailovani, nacez v sobe mixovala staticky a nestaticky pristup na zhruba 1500 radkach kodu, ktery se mnohdy az napadne opakoval diky tomu tomu ze nekolik funkci delalo to same jen nad jinymi promennymi, dale spolu s nevhodnym pouzivanim pole, coz je videt hodne casto.
Bez dedicnosti by nebylo OOP.

Procedurální kód kupodivu není kód odzhora dolu, ale dobře strukturovaný do procedur a funkcí.
Tvrzení, že bez dědičnosti by nebylo OOP je přehnaně silné. Dědičnost je až druhořadým aspektem objektového paradigma. Základním je kompozice a ta by měla být před dědičností preferovaná.

No já bych řekl, že základem jsou spíš věci jako zapouzdření, information hiding a podobně. Kompozice vs. dědičnost je spíše téma do praxe.

Základní jsou identita, zpouzdření a kompozice. Bez kompozice by neměl OO návrh smysl. :) Pěkně probrané je to ve spotu http://blog.vyvojar.cz/pbouda/archive/2008/07/30/fundamenty-objektoveho-paradigmatu.aspx

Když už se zapojujeme do té diskuze o tom, co je vlastně OOP, já si vypomůžu Kentem Beckem: „The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment.“ (http://c2.com/doc/oopsla89/paper.html)
V tomto směru mi OOP pomáhá popisovat problém přirozenou cestou. Ano, toto je možné v Obj-C, Smalltalku, Selfu. V Javě, C#, PHP se OOP redukuje na nějakou kompozici, posílání zpráv, zapouzdření a to je dost málo, kvůli tomu bych se OOP vlastně vůbec neučil (a to už bych radši dělal funkcionální programování, kdyby bylo OOP jen o těch tisíckrát provařených paradigmatech).

Mně šlo hlavně o to poukázat, že OOP se nám nesmrskává na dědičnost. Vlastně můžu mít objektový jazyk bez podpory dědičnosti a stále to bude plně objektový jazyk. :)

Máš pravdu, jen jsem měl na mysli to, že primárnost nebo sekundárnost pojmů nemusí podle mého souviset s užitečností v praxi (viz tvé „základním je kompozice a ta by měla být před dědičností preferovaná“ – souhlasím, ale IMHO to nevychází z teoretické podstaty OOP).

Na windows používám „distribuci“ XAMPP:
http://www.apachefriends.org/en/xampp.html
pear i phpunit tam je, ale starý (2.3.6 asi), takže je nejprve potřeba odinstalovat:
pear uninstall phpunit2
pear uninstall phpunit
a až pak instalovat dle návodu v článku.

Postupoval jsem podle návodu, ale i přesto mi PHPUnit nefungoval. Jakmile jsem napsal příkaz „phpunit“ někam jinam, než mimo složku, ve které se nacházel, tak se nic nestalo.
Bylo potřeba nastavit systémovou proměnou PATH. To se udělalo takto:
Počítač->Vlastnosti->Proměnné prostředí->Systémové proměnné a tam je třeba najít proměnnou s názvem „Path“, editovat jí, přidat středník na konec a za něj cestu ke složce PHP.
Jakmile jsem toto udělal, tak už funguje příkaz „phpunit“ odkudkoliv.
Možná to bylo triviální, ale věřím tomu, že ne každý toto ví a proto doufám, že můj stručný návod pomůže.