DevProTalk - Unit-Testing - overkill ili ne?

DevProTalk (http://www.devprotalk.com/index.php)

- Programiranje (http://www.devprotalk.com/forumdisplay.php?f=23)

- - Unit-Testing - overkill ili ne? (http://www.devprotalk.com/showthread.php?t=5608)

Unit-Testing - overkill ili ne?

za vecinu projekata kojom se ja bavim (a verujem da se ovo odnosi na vecinu) unit testing je overkill, makar po meni

Split teme: 2 pitanja u vezi MySQL-a i PHP-a u vezi datuma.

Citat:

Originalno napisao cvele (Napišite 56440)

za vecinu projekata kojom se ja bavim (a verujem da se ovo odnosi na vecinu) unit testing je overkill, makar po meni

Da li je overkill ili ne zavisi od više stvari (evo par po meni bitnih):

1. Koliko je osnovno to što treba da testiraš? Npr, ja imam testove za stvari na koje oslanja cela aplikacija i u kojima NE SME da bude problema (klase za rad sa bazom, datumima, keširanje i slično).

2. Koliko često osvežavaš aplikaciju i koji downtime sebi smeš da dozvoliš? Ako radiš CMS za auto-perionicu iz Bečeja nije problem, ali ako praviš web servis koji ljudi plaćaju po $50 - $150 mesečno nema zajebancije. Ja se u takvu rabotu nikada ne bih upuštao bez ozbiljne pokrivenosti koda testovima.

3. Koliko su tvoji kupci tolerantni kada su bugovi u pitanju? Sa nekim tipovima aplikacija možeš da se izvučeš sa većom količinom bugova, sa nekim ne. Zavisi šta radiš, kome prodaješ i koliko to košta.

Citat:

Originalno napisao Ilija Studen (Napišite 56441)

1. Koliko je osnovno to što treba da testiraš? Npr, ja imam testove za stvari na koje oslanja cela aplikacija i u kojima NE SME da bude problema (klase za rad sa bazom, datumima, keširanje i slično).

Upravo zato ne bi trebalo pisati svoj frejmvork. Ne samo da treba održavati kôd samog frejmvorka već i gomilu kôda u testovima za taj frejmvork.

Sa 2. i 3. se slažem.

---
moderator: izvući u novu temu?

ilija, banalizovao si stvari.

unit testing nece uciniti aplikaciju 100% bug free.

Na simple aplikacijama veoma je jednostavno istestirati funkcionalnosti rucno i cesto ce obavljanje unit testinga odneti vise vremena nego kada bi se proslo kroz situacije rucno.

Sto se tice critical klasa (db apstrakcija etc), slazem se da je jako bitno da budu temeljno istestirane, ali da li je unit testing pravi izbor to je pitanje.

Iskreno unit testing po meni ima smisla samo u slucaju da imas "inzinjerski" pristup projektu. Taj pristup podrazumeva uml, cases, izrada, testing. Bez takvog, ili slicnog, pristupa projekat izlazes prakticno istom riziku od bugova kao i bez unit testinga (ako se slozimo da se najveci broj bugova stvara previdom neke od mogucih situacija).

Edit:
Ok deluje da vas ima nekoliko koji aktivno primenjujete unit testing, pa me zanima koji/dali koristite neki framework.
Do sada sam se jedino baktao sa PhpUnit

Aplikacije neće biti bug free, ali će testiranje osetno smanjiti količinu bugova. Ukoliko je aplikacija iole složena testiranjem ćeš naći i pokrivit slučajeva koje teško možeš skontati ručno testirajući, bez da pustiš aplikaciju da je drugi koriste. Uvek je bolje da bug nađeš i pokrpiš sam nego da ti ga prijavi mušterija...

Da li je unit testing pravi izbor ili nemam pojma. Znam samo da radi posao...

Citat:

Originalno napisao cvele (Napišite 56444)

Iskreno unit testing po meni ima smisla samo u slucaju da imas "inzinjerski" pristup projektu. Taj pristup podrazumeva uml, cases, izrada, testing. Bez takvog, ili slicnog, pristupa projekat izlazes prakticno istom riziku od bugova kao i bez unit testinga.

Ne bih se složio. Unit testiranje fino leži i školskom i attack načinu rada. Sve je samo stvar discipline i pristupa. Ti na unit testiranje sada gledaš kao na problem zato što nemaš nikakvu pokrivenost i nikakve test navike. Treba vremena i za jedno i za drugo, ali kada dođeš do toga pisanje testova postane deo svakodnevice... Kao pisanje inline dokumentacije na primer...

Mozda si upravu, istina je da nemam naviku niti praksu unit testinga.

Zanima me po cemu se razlikuje broj slucajeva koje napises/pokrijes unit testingom od broja slucajeva koje ti smislis ? Ipak sve slucajeve ti moras da predvidis i napises, ili gresim ?

Citat:

Originalno napisao cvele (Napišite 56450)

Razlika je automatizaciji testiranja. Saberi vreme koje ti je potrebno da ručno isprobaš sve moguće kombinacije unosa podataka npr * postojećeg stanja sistema(baza) kad god menjaš neku funkcionalnost i biće ti jasno šta je ekonomičnije.

Moram još stvari da dodam da neko ne bi pomislio da je vreme jedina dobit.

* Jedna od ključnih vrednosti unit testova je da pomaže u pisanju boljeg kôda. Pošto unit testovi treba da rade u izolaciji(ne bi trebalo da kontaktiraju bazu npr ili neki eksterni servis i sl.) da biste uopšte napisali test, kôd koji se testira mora da bude struktuiran na taj način da je moguće simulirati(mock) takve servise(npr izdvojiti takvu funkionalnost u drugu funkciju/klasu).

* Takođe još jedna stvar koja se tiče podizanja kvaliteta kôda koji se testira je da smanjuju strah od refaktorisanja. Ako kôd radi ali nije dobro napisan i nema pokrivenost testova, najverovatnije se nećete usuditi da išta menjate.

* Ako je u pitanju timski razvoj, olakšavaju korišćenje i izmene tuđeg koda, nema potrebe za dokumentovanjem primera korišćenja, imate primere koji rade(bukvalno).

Tako sam i mislio, prakticno i nema razlike osim u automatizaciji.

Samim tim moj definitivni zakljucak je da kada se radi na resenju nekog softvera za klijenta koje se isporucuje "kljuc u ruke", unit test jeste overkill

Citat:

Originalno napisao cvele (Napišite 56458)

Tako sam i mislio, prakticno i nema razlike osim u automatizaciji.

Nije baš skroz tačno. Kaizen je pomenuo kvalitet koda. Ako testove pišeš pre nego što kodiraš imaćeš čistije i bolje definisane interfejse, manje zavisnosti između pojedinačnih slojeva aplikacije itd.

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.

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

Po meni je unit test must have :-)

ovo je kod od one moje klase

PHP kôd:


		
			
<?php 



    class MySQL_date  

    { 

        // site::http://boonedocks.net/mike/archives/137-Creating-a-Date-Range-Array-with-PHP.html 

        public static function createDateRangeArray($strDateFrom, $strDateTo)  

        { 

            // takes two dates formatted as YYYY-MM-DD and creates an 

            // inclusive array of the dates between the from and to dates. 



            // could test validity of dates here but I'm already doing 

            // that in the main script 



            $aryRange=array(); 



            $iDateFrom=mktime(1,0,0,substr($strDateFrom,5,2),     substr($strDateFrom,8,2),substr($strDateFrom,0,4)); 

            $iDateTo=mktime(1,0,0,substr($strDateTo,5,2),     substr($strDateTo,8,2),substr($strDateTo,0,4)); 



            if ($iDateTo>=$iDateFrom) { 

                array_push($aryRange,date('Y-m-d',$iDateFrom)); // first entry 



                while ($iDateFrom<$iDateTo) { 

                $iDateFrom+=86400; // add 24 hours 

                array_push($aryRange,date('Y-m-d',$iDateFrom)); 

                } 

            } 

             

            return $aryRange; 

        } 

      

        // convert string in format dd.mm.YYYY to MySQL format http://dev.mysql.com/doc/refman/5.0/en/datetime.html YYYY-MM-DD 

        // example 18.04.2008 to 2008-04-18 

        public static function ddmmYYYYtoYYYYMMDD($date) 

        { 

            $parts = explode(".", $date); 

             

            $new_date = $parts[2] . '-' . $parts[1] . '-' . $parts[0]; 

             

            return $new_date; 

        }  

         

    } 

       

?>

A evo koda za unit test, koristio sam http://simpletest.sourceforge.net/en...mentation.html

PHP kôd:


		
			
<?php

    require_once('../simpletest/autorun.php');

    require_once('../class/MySQL_date.php');



    class TestOf__MySQL_date extends UnitTestCase 

    {

        function test__ddmmYYYYtoYYYYMMDD()

        {

            $this->assertEqual( MySQL_date::ddmmYYYYtoYYYYMMDD('16.06.2008'), '2008-06-16');

            $this->assertEqual( MySQL_date::ddmmYYYYtoYYYYMMDD('01.01.2009'), '2009-01-01');

        }

        

        function test__createDateRangeArray()

        {

            $this->assertEqual( MySQL_date::createDateRangeArray('2008-06-16', '2008-06-16'), array( '2008-06-16' ) );

            $this->assertEqual( MySQL_date::createDateRangeArray('2008-06-16', '2008-06-17'), array( '2008-06-16', '2008-06-17' ) );

            

            $result = MySQL_date::createDateRangeArray('2008-06-30', '2008-07-02');

            $expectedResult = array( '2008-06-30', '2008-07-01', '2008-07-02' );

            if( !$this->assertEqual( $result, $expectedResult ) )

            {

                $this->dump( $result );

            }

            

            $result = MySQL_date::createDateRangeArray('2008-12-30', '2009-01-02');

            $expectedResult = array( '2008-12-30', '2008-12-31', '2009-01-01', '2009-01-02' );

            if( !$this->assertEqual( $result, $expectedResult ) )

            {

                $this->dump( $result );

            }

            

            $result = MySQL_date::createDateRangeArray('2008-02-27', '2008-03-02');

            $expectedResult = array( '2008-02-27', '2008-02-28', '2008-02-29', '2008-03-01' ,'2008-03-02' );

            if( !$this->assertEqual( $result, $expectedResult ) )

            {

                $this->dump( $result );

            }

            

            $result = MySQL_date::createDateRangeArray('2009-02-27', '2009-03-02');

            $expectedResult = array( '2009-02-27', '2009-02-28', '2009-03-01' ,'2009-03-02' );

            if( !$this->assertEqual( $result, $expectedResult ) )

            {

                $this->dump( $result );

            }

        }

    }

?>

Mogao sam ja to i rucno testirati ali bih sigurno izgubio isto toliko vremena koliko mi je trebalo da napišem taj test(oko 30min i napominjem da je ovo prvi unit test koji sam napisao za PHP, jer inace mislim da bi ovo osoba mogla učiniti za 5-10minuti) i ne bih mogao ponovno pokrenuti taj test kada god poželim.

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...