Zend PHPUnit testing

Započeo Marko Аcović, 22.11.2010, 11:57

prethodna tema - sledeća tema

Marko Аcović

Da li je neko radio unit testove u Zend-u primenom PHPUnit-a?
Postoji li neki dobar tutorijal za ovo osim standardne ZF dokumentacije?

holodoc

Jesi li pokušao na zvaničnoj stranici PHPUnit-a? Postoji nekoliko sličnih projekata koje nosi identično ime ali samo sajt sa nemačkim TLD-om je pravi PHPUnit  :dzavo:

Jako detaljno uputstvo i tutorijale ćeš naći na http://www.phpunit.de/manual/current/en/index.html gde je objašnjeno sve od ciljeva PHPUnita preko instalacije do objašnjenja svih metoda klasa itd.

Koliko ja znam ne postoji neka bitna razlika u testiranju običnog PHP koda i koda pisanog uz pomoć bilo kog frameworka jer PHPUnit testira kod a ne framework.
<?php
abstract class Ignorance extends Stupidity implements Unavoidable 
    private function 
__construct(){
        
parent::__destruct();
    }; 

// EOF -> life.php

holodoc

E da još nešto. Ako imaš nameru da koristiš Sellenium NetBeans ti ima nativnu podršku za njega pa možeš malko da se igraš :)

http://netbeans.org/kb/docs/php/phpunit.html
<?php
abstract class Ignorance extends Stupidity implements Unavoidable 
    private function 
__construct(){
        
parent::__destruct();
    }; 

// EOF -> life.php

gagi

Da li je neko pokušato test driven development? Voleo bih da čujem iskustva ako je neko probao, bilo u PHP-u bilo u nekom drugom jeziku.

Marko Аcović

Znam za TDD (mnogi ga koriste) ali ga nisam probao jos. Ako budem probao, prenecu utiske :)

holodoc

22.11.2010, 18:14 #5 Poslednja Izmena: 22.11.2010, 18:17 od holodoc
Na TDD u bukvalnoj formi ćeš danas malo teže da naletiš jer se obično zbog nedostatka vremena koristi malčice modifikovan ciklus koji eliminiše kompletan mockup korak na početku i odmah prelazi na implementaciju. Ne kažem da nema projekata koji se verovatno pridržavaju kompletne procedure ali sistemi za verzionisanje softvera (SVN, Git, Mercurial) su danas postali toliko moćni da se jednostavno ta faza pisanja mockup testova vremenski više ne isplati kada najobičniji rollback na prethodnu reviziju, ukoliko se pojavi neki krupan problem, štedi mnogo više vremena i živaca. Čak štaviše Git je napisan baš specifično da omogući developerima da se veoma lako "šetaju" između revizija i isprobavaju nove stvari a da se po potrebi veoma lako vrate na prethodne revizije.

Evo primera radi jednog tipičnog ciklusa izrade softvera koji se bazira na SVN sistemu iz perspektive jednog od developera (pretpostavka je da developer ima urađen checkout na trunk folder kod sebe lokalno). Layout repozitorijuma je takav da trunk naravno sadrži aktuelan (master branch) kod, branches sadrži bar jednu granu koja služi isključivo za kloniranje trunk koda na kraju radnog dana a tags u ovom slučaju nije toliko bitan.

1) Pre bilo kakvog dodavanja novih funkcionalnosti ili izmena developer radi klasičan update svog repoa da ne bi bilo kasnijih konflikata sa kodom preostalih developera.

2) Developer vrši izmene na kodu tj. recimo dodaje novu funkcionalnost nakon čega radi commit u trunk folder čime kod postaje dostupan svim ostalim developerima.

3) Pri kraju radnog dana sistem automatski (kod SVN-a se uglavnom koriste ili post-commit hook-ovi ili recimo neka druga automatika) generiše tzv. nightly-build pakete koji su dostupni zasebno za preuzimanje (obično ukoliko je u pitanju open source projekat ograničenom broju ljudi, beta testera recimo, stoji na raspolaganju skidanje ovih paketa) dok se u kod iz trunka prebacuje u branches granu koja je specijalno namenjena beta testiranju.

4) Beta testeri sada imaju mogućnost da dok developeri nastavljaju da rade u trunku testiraju novi kod u okviru branches grane i da ukoliko naiđu na probleme prijave problem u bugtrackeru.

Ovde se sad proces potencijalno grana i mogu da postoje dva načina kako se organizuje komunikacija između beta testera i developera.

5.1) Developeri na osnovu prijava u bugtrackeru vrše ispravku u trunk folderu i sistem na kraju dana kreira odgovarajući nightly-build sa novim ispravkama a u okviru branches beta testing grane se sada nalazi i novi commit sa ispravkama koje beta testeri ponovo proveravaju i eventualno prijavljuju dalje probleme.

5.2) U ovom slučaju beta-testeri su ti koji ispravljaju kod i nakon završenih ispravki vrše spajanje (merge) svoje loklane beta-testing grane sa trunk-om. Nakon spajanja beta-testeri rade momentalan checkout trunka i proveravaju da kojim slučajem spajanje nije napravilo neku dodatnu kontraindikaciju na kodu koji je dobijen spajanjem aktuelnog koda u trunku i verzije koja je ispravljana u beta-testing grani.

6) Ukoliko se ispostavi da je u celom procesu došlo do nekog nerpedviđenog problema trunk i branches može u bilo kom trenutku da se "rollback-uje" na prethodnu stabilnu reviziju i da se proves započne od početka ili da se jednostavno ako za to postoji potreba napravi posebna grana od trunka koja će se detaljnije pozabaviti novom funkcionalnošću i to potpuno nezavisno od trunk-a.

Dakle očigledno savremeni sistemi za verzionisanje omogućavaju neke stvari koje pre možda nekih desetak godina nisu bile ni zamislive. Git je postao posebno popularan kod projekata koji zahtevaju rad velikog broja ljudi na njima pri čemu treba da se obezbedi i veliki stepen autonomije pojedinačnih developera (zato Git i spada u tzv. distribuirane sisteme za verzionisanje - DVCS) dok recimo SVN spada u centralizovane sisteme za verzionisanje. Naravno svaki ima svoje prednosti i mane :) Takođe, Git ima i svoju online verziju centralizovanog sistema za vođenje računa o repoima (http://github.com/) a nešto slično ima i Mercurial (http://bitbucket.org/).
<?php
abstract class Ignorance extends Stupidity implements Unavoidable 
    private function 
__construct(){
        
parent::__destruct();
    }; 

// EOF -> life.php

gagi

Git jeste odličan i već duže vreme ga koristim za sve projekte na kojima radim i u tome se apsolutno slažemo ali se ne slažem da je TDD baš retka pojava mada koliko sam uspeo da primetim u PHP-u i nije baš zaživeo. Pisanjem testove PRE koda programer mora da sagleda šta je to problem koji rešava i tek kada dobro sagleda može pristupiti pisanju testa. Dakle testovi teraju programera da pre nego što pristupi pisanju koda napravi dobru analizu, što bez testova uglavnom nije slučaj (ko će da se smara sa detaljnim čitenjem dokumentacije). Dalje, testovi su tu da olakšaju refaktorisanje posebno u slučajevima kada kod preuzme nakon par meseci neki drugi programer da bi izvršio neke izmene - ako napravi grešku koja utiče na postojeći kod testovi će pasti ako su kvalitetno pisani.

Pošto smo se dotakli teme testiranja, postoji još jedna stvar koju bih voleo da spomenem a to je rad u parovima koji je kao i TDD sastavni deo ekstremnog programiranja koga smatram najboljim pristupom za razvoj softvera. Princip je jednostavan, jedan programer piše kod dok drugi sedi pored njega i vrši review svake linije koda a nakon izvesnog vremena menjaju uloge. Mada ovo izgleda kao uludo trošenje resursa firme analize pokazuju da je par programera tek nekih 15% sporiji od dva odvojena programera a kvalitet koda je drastično veći. E sad ono što se meni posebno sviđa - ping-pong programiranje u parovima. Ovde posmatrač piše test a onaj ko programira dužan je da napiše kod koji će naterati test da prođe. Mislim da je ovo rešenje kojim se izvlači maksimum iz programera a pri tome se dobija na kvaltitetu koda. Na žalost u zemlji Srbiji se ništa ne radi kako treba pa tako odavno nema ozbiljnih projekata na kojima bi se ovakve stvari primenjivale. Teško da ovde bilo koga zanima kvalitet koda koji se napiše, mogućnost njegovog ponovnog korišćenja i lakoće u održavanju.  "Kompajlira se, dakle radi" je često najozbiljnije testiranje koje postoji.

P.S. Evo par linkova koje mogu da pogledaju oni koji nisu upoznati sa XP-om i stvarima koje sam spomenuo.
http://en.wikipedia.org/wiki/Extreme_programming
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/Pair_programming
http://msdn.microsoft.com/en-us/magazine/cc163982.aspx
http://c2.com/cgi/wiki?ExtremeProgramming

holodoc

23.11.2010, 15:38 #7 Poslednja Izmena: 23.11.2010, 15:42 od holodoc
I opet da se ponovim po ko zna koji put, sve to zvuči lepo i logično na papiru ali ako ikada dođeš u situaciju da početnu koncepciju menjaš do te mere da ciljeve u projektu postavljaš svakom sledećom iteracijom koda, što je inače i bukvalno jedna od stavki koje čine osnovu TDD-a, onda je sva prilika da si se već debelo našao u neobranom gvožđu. Najčešći razlog koji će te i dovesti u takvu (s oproštenjem) "šituaciju" jesu klijenti koji imaju običaj da svoje zahteve menjaju češće nego Drina tok i koji tvoj autoritet kao profesionalca dovode u pitanje pokušajima nametnanja svog rešenja. Od te tačke pa nadalje projekat u savremenom ekonomskom modelu razvoja softvera kreće na dole!

Citat: gagi44  23.11.2010, 00:29...mada koliko sam uspeo da primetim u PHP-u i nije baš zaživeo.
I jel to po tebi dobro ili loše? :)>- Čisto preventivno u slučaju da je odgovor negativan po PHP da konstatujem u njegovu "odbranu" da je valjda jasno da metodologiju izrade i testiranja softvera ne bira razvojno okruženje (programski jezik) već razvojni tim ili project manager. Reći da je metodologija slabo zaživela u nekom programskom jeziku je isto što i reći da se određeni softverski design pattern slabo koristi u nekim programskim jezicima čije specifikacije omogućavaju implementaciju tih design pattern-a. To da li ću ja da koristim određen pristup prilikom izrade softvera ili ne danas ne diktiraju više želja za estetski lepim kodom koji može da se okiti lepim skraćenicama tipa TDD, XP i sl. već isključivo ekonomski i vremenski faktor.

Citat: gagi44  23.11.2010, 00:29Pisanjem testove PRE koda programer mora da sagleda šta je to problem koji rešava i tek kada dobro sagleda može pristupiti pisanju testa. Dakle testovi teraju programera da pre nego što pristupi pisanju koda napravi dobru analizu, što bez testova uglavnom nije slučaj (ko će da se smara sa detaljnim čitenjem dokumentacije). Dalje, testovi su tu da olakšaju refaktorisanje posebno u slučajevima kada kod preuzme nakon par meseci neki drugi programer da bi izvršio neke izmene - ako napravi grešku koja utiče na postojeći kod testovi će pasti ako su kvalitetno pisani.

Sačekaj... Ti ozbiljno ovde hoćeš da kažeš da sa jedne strane stavljaš akcenat na detaljnu analizu problema pre pisanja koda a sa druge strane čitanje dokumentacije smatraš "smaranjem" :I Izvini ako ovo možda bude zvučalo grubo ali to je po meni čist odraz lenjosti i amaterizma. Kako uopšte čekuješ da na taj način uspešno analiziraš problem i "nakalemiš" svoj kod na postojeći ako se prethodno ne upoznaš sa početnim specifikacijama projekta kroz njegovu  dokumentaciju? :o

Detaljna i precizna dokumentacija projekta je ubedljivo najvažniji resurs za uspešan razvoj i opstanak bilo kakvog softvera. ENDE!


Ukoliko su se prethodni developeri pridržavali normi usvojenih odabirom nekog kvalitetnog softvera za automatsku dokumentcaiju koda (PHPDoc, JavaDoc, Doxygen) problema jednostavno ne može da bude bilo da se projekat nastavlja ili forkuje za sedam dana ili sedam godina. Da je priča drugačija PHP bi verovatno bio među prvim projektima koji je propao a on se posle toliko godina i dalje dobro drži uz redovan milionski broj posetilaca njegovog sajta sa dokumentacijom na dnevnom nivou :)

Citat: gagi44  23.11.2010, 00:29Pošto smo se dotakli teme testiranja, postoji još jedna stvar koju bih voleo da spomenem a to je rad u parovima koji je kao i TDD sastavni deo ekstremnog programiranja koga smatram najboljim pristupom za razvoj softvera.
I ovo ću morati da prokomentarišem. "Najbolji pristup za razvoj softvera" kao generalno rešenje jednostavno ne postoji. Ono što u jednom slučaju deluje kao optimalno rešenje u drugom može da bude potpun overkill koji može da sa'rani projekat u startu. Za softver je bitno prilagođavanje i korišćenje onih alata i tehnologija koje s jedne strane uspešno pokrivaju zahteve projekta a sa druge nude dovoljno "lufta" za rešavanje stavki sa kojima se developeri još uvek nisu susretali jer gotovo svaki projekat je sastavljen od poznatih stvari koje se rešavaju rutinski i onih za koje je potreban mali brainstorming  :sex: S druge strane kako zamišljaš rad u parovima na recimo open source projektima (posebno globalnim) gde ostale učesnike u projektu gledaš samo preko nišana repozitorijuma i bugtrackera? :) Preveliki je broj situacija gde rad u parovima jednostavno nije izvodljiv a da ne napominjem opšte poznatu činjenicu da programeri umeju da budu poprilično sujetni ljudi i da gledanje njihovog koda "preko ramena" ume da izazove potrebu u njima da posmatrača odalame ili pošalju na mesto čije bi pominjanje ovde spadalo u domen vulgarnog izražavanja :whackbutt:

Citat: gagi44  23.11.2010, 00:29Na žalost u zemlji Srbiji se ništa ne radi kako treba pa tako odavno nema ozbiljnih projekata na kojima bi se ovakve stvari primenjivale. Teško da ovde bilo koga zanima kvalitet koda koji se napiše, mogućnost njegovog ponovnog korišćenja i lakoće u održavanju.  "Kompajlira se, dakle radi" je često najozbiljnije testiranje koje postoji.
Bolje nemoj da vučeš za jezik ljude sa ovog foruma koji bi imali šta da kažu na temu kvaliteta koda koji dolazi s' "one strane grane" ;) Kakvih tu šokova možeš ponekad da nađeš učiniće ti se da je svaki naš srednjoškolac koji je tek prošao osnovnu obuku za rad u Pascalu Bill Gates. Indija, Kina, Južna pa i Severna Amerika ponekad su pravi raj za kvalitetan kod sa obiljem materijala za slikovnice kojima samo još flomasteri fale pa da žurka bude kompletna :D Nadam se samo da će se dotični članovi javiti da makar posvedoče iz ličnih iskustava na šta su sve nailazili u svojoj karijeri.

Da rezimiram sve ove pisanije do sada.

@gagi44
Sve alternativne metodologije izrade softvera koje si ovde naveo zvuče lepo na papiru ali su u isto vreme u savremenom modelu razvoja softvera, koji se tokom poslednih godina više orijentisao na ekonomski aspekt nego na kvalitet koda, takve metode jednostavno nisu održive. Tokom samo poslednjih deset godina klasičan pristup cepidlačenja oko kvaliteta koda je zamenjen RAD sistemima čiji je osnovni cilj da se projekti završe na vreme čak i po cenu da finalni proizvod bude bloatware kojem treba bar još onoliko vremena koliko je razvijan da se uklone razne bubice i nedostaci. Jednostavno danas tako sistem funkcioniše i project manageri uglavnom nisu preterano zainteresovani da izlaze van okvira do sada zacrtanih tokova procesa razvoja softver samo da bi potvrdili ili opovrgli činjenice koje su iznesene u jednoj, pa moraćeš da priznaš, poprilično akademski orijentisanoj ideji. Ako ti je osnovna namera da se baviš akademskim istraživanjem metodologija razvoja softvera onda si verovatno na pravom putu ali ako imaš nameru da se upustiš u timski razvoj namenskog softvera bojim se da ćeš doživeti jako neprijatno iznenađenje kada na sopstvenoj koži osetiš bilo šta što sam pominjao u poslednjih nekoliko postova.

Još jednom iako sam citirao tvoje postove moji odgovori su imali za cilj isključivo da dopru do šire populacije ovog foruma koju potencijalno interesuje šta mogu da očekuju ako reše da se kasnije bave razvojem softvera a sa svojih sada već više od dvadeset godina koliko sam proveo za računarom verujem da mogu da se u raspravu uključim sa ajde da kažem poprilično kompetentnim viđenjem cele situacije. Ako sam negde u priči bio i malo grub sa izborom reči to nije zbog toga što mi je to bila namera već jednostavno što u ovako "brzinsko-maratonskom" vidu izražavanja kod mene obično radi sistem "što na um to na drum" ;)
<?php
abstract class Ignorance extends Stupidity implements Unavoidable 
    private function 
__construct(){
        
parent::__destruct();
    }; 

// EOF -> life.php

gagi

Ceo ovaj koncept živi u praksi i sve više ljudi ga aktivno koristi. Ako ne veruješ meni i smatraš me lenjim amaterom onda veruj Kent Beck-u, Ward Cunningham-u ili Martin Fowler-u jer ipak ono što oni rade zaslužuje respekt a svakako su iskusniji od tebe i mene u paketu. Takođe, nisam rekao da ja ne čitam dokumentaciju (izvrnuo si moje reči) već da je to čest slučaj - ljudi  u žurbi ne posvete dovoljno pažnje detaljima pa ih kasnije to mnogo košta. Iz mog iskustva klijenti često ne menjaju zahteve, već postoji tačno definisani zahtevi i jedan fini čika (product manager) koji je stalno tu da kontroliše njihovu implementaciju i eventualno reaguje na promene. Kao što rekoh, u zemlji Srbiji se ništa ne radi kako treba, tako da ako naletiš na vlasnika SUR "Mali raj" koji želi dostojno da prezentuje ponudu pića u svom lokalu siguran sam da takav često menja svoje zahteve ali čak i tada mušterija je uvek u pravu - "When he says jump, you say how high". Što se najboljeg metoda tiče, slažem se da ne postoji ali postoji nešto što se zove "best practice" a po meni je ona data ukratko ovde
http://agilemanifesto.org/iso/sr/

I tako, možemo ti i ja do sutra da se prepucavamo da li je starije kokoška ili jaja ali nemam dovoljno vremena za takve stvari tako da odustajem od dalje rasprave na ovu temu. Želeo sam samo da kolegi predložim metodu razvoja (a on je ipak pitao za testiranje) koja po meni zavređuje pažnju a ne da mu pokažem kako sam ja pametan, dobar i lep.

ENDE!