17. 06. 2008. | #11 |
dinosaurus
Master
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
|
Ukratko: kad god napraviš i najmanju izmenu koda, postoji šansa da si nešto zabrljao i jedini način da se koliko-toliko uveriš da je sve OK je testiranje. E sad, možeš i svaki put da testiraš ručno (ali se i tada drži spiska testova inače ćeš nešto da zaboraviš) ili ako imaš automatske testve, startuješ ih i odeš da skuvaš kafu
Ja lično preferiram drugi način. Ako pogledate moj open-source projekat http://utfcpp.svn.sourceforge.net/viewvc/utfcpp/v2_0/ primetićete da je više koda namenjeno testiranju nego samoj funkciji biblioteke. Naravno, kad se razvija aplikacija a ne biblioteka, ne treba biti toliko rigorozan, ali je i tad automatsko testiranje jako korisna stvar. Npr, dobro je imati automatizovane funkcijske testove umesto unit-testova u tom slučaju - na kraju krajeva interesuje te funkcionalnost aplikacije a ne toliko ispravnost svakog delića koda. |
17. 06. 2008. | #12 |
Ivan Dilber
Sir Write-a-Lot
|
radi se pre svega o velicini i komplikovanosti koda sa kojim radis. Ako imas neku funkcionalnost koju si pisao davno, ili je uopste nisi ti pisao, kako ces da testiras da li radi i dalje nakon sto si npr. promenio nesto u bazi, ili izmenjao neku klasu?
Mozes da probas direktno u test aplikaciji da li se pojavljuje greska, ali onda nikad nisi siguran da li ces prevideti neki suptilni side-effect, i cak i kad nadjes gresku ne znas tacno gde je. Mozes da probas da provaljujes iz koda kako on radi, pa da na osnovu toga testras, ali time gubis vreme, i opet nisi siguran u rezultate. S druge strane ako je za tu klasu odmah napisan test, tada kad je autor imao u glavi ceo problem i znao savrseno koje su opcije, ipak su znatno vece sanse da su pokriveni svi bagovi i problemi, i kad nastane problem mozes da dobijes smislenu poruku gde je problem i kako da ga resis. Stvar je slicna kao sa OOP, cesto je brze napisati samo funkciju koja nesto radi, nego praviti klasu, ali ti to olaksava odrzavanje kasnije. Tako da unit testing jeste overkill u slucaju da: - sve radi kako treba i nece se cesto i bitno menjati - dovoljno mala aplikacija da brzo mozes da vidis sta kako radi - u zurbi si da zavrsis aplikaciju, a za bug fixing ces imati vise vremena kasnije (ovo nazalost nije uopste retko) Ovo je naravno veliki procenat klasicnih web aplikacija, ali u ostalim slucajevima nije overkill, nego ti naprotiv stedi vreme... EDIT: Dragi Tata je skroz u pravu, testovi funkcionalnosti su najbitniji, jer je neke side-effects tesko primetiti testirajuci odvojeno klasu po klasu
__________________
Leadership is the art of getting people to want to do what you know must be done. Poslednja izmena od ivanhoe : 17. 06. 2008. u 17:25. |
18. 06. 2008. | #13 |
profesionalac
Qualified
Datum učlanjenja: 22.09.2007
Lokacija: Split
Poruke: 111
Hvala: 8
39 "Hvala" u 10 poruka
|
Po meni je unit test must have :-)
ovo je kod od one moje klase
PHP kôd:
PHP kôd:
Po meni je itekako normalo da svaki cod(program, skripta) ima i neki (kod, program) koji ga može automatski testirati. To izgleda da se možda ne isplati kod malih projektica ili programćica(istina ne pisem nikakav test za linux skripte od par desetaka linija) ali ako ih ikada zatreba israviti onda osoba shvati da je bolje bilo da ih je imala. Ima ja jedno pitanje: Sta se pod PHP-om(webom) može koristiti za testiranje iznad unit testa, mislim na testiranje cijele aplikacije... |
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Što koristite za unit testing u PHP-u ? | misko_ | PHP | 3 | 27. 05. 2008. 16:53 |
Unit testing JavaScripta | Ilija Studen | (X)HTML, JavaScript, DHTML, XML, CSS | 0 | 01. 06. 2007. 12:34 |
Unit testing veb aplikacija? | jablan | Programiranje | 8 | 29. 03. 2006. 12:52 |
Yahoo Testing New Homepage | Denis_Radenkovic | Web design, Layout, User Interface | 5 | 12. 03. 2006. 11:15 |
Unit Testing i analiza gresaka | zextra | PHP | 1 | 05. 02. 2006. 17:31 |