Forum » Programiranje » Unit testing - se poslužujete?
Unit testing - se poslužujete?
U2ros ::
Veliko moje kode je po naravi take, da bi jo lahko unit testal. Načeloma mi je všeč tudi ideja, da najprej spišeš unit teste in nato dejansko kodo, ki jo testi testirajo, ampak vedno mi zmanjkuje časa, vedno grem direktno pisat kodo, testov 'za nazaj' pa sploh ne pišem, debugging in bugfixi se pa izvajajo kar skozi uporabo programa (delam v manjšem podjetju, tak process miniomalno vpliva na zastoje, itn). Kakšna je vaša izkušnja ali morda strategija glede testiranja kode?
Smurf ::
Testerji in unit testing sta 2 razlicni stvari, ki preverjata stvari iz dveh razlicnih zornih kotov. Unit teste naj bi naceloma pisali programerji in ne testerji. Mi imamo oboje, zraven pa se continuous integration. Mogoce bi bilo smiselno omeniti se code review, ki pa si ga delajo devi med sabo (na ta nacin precej poceni eliminiras kar nekaj buggov). Ko imas enkrat program, ki v celoti zavzema nekaj miljonov vrstic, je tezko drugace sploh preziveti.
U2ros ::
Edini 'pravi' dev sem, programi so zgolj za interno uporabo, dinamika spreminjanja naših workflowov pa je izjemna, zato se softwer nonstop dograjuje in spreminja. Določeni namenski moduli so s časom z dolgotrajno uporabo postali dovolj robustni da jim zaupam, ampak ravno ta zadnji stavek je nekaj kar načeloma brez pravega testiranja ne bi smel trditi. Bolj se sprašujem, ali mi uvedba unit testov odtehta kasnejsi cas potreben za debugging. Ker nimam toliko izkusenj s tem me zanimajo izkusnje drugih.
jype ::
"Integration testing" je IMO še pomembnejše, ampak bržkone iz mene v tem primeru govori "ops guy".
Spoštujem "test driven development", razumem pa tudi nekatere z njim povezane frustracije (kot je znatno počasnejši čas razvoja, ker je treba vedno najprej popraviti napačen test, potem pa še napačen program).
Spoštujem "test driven development", razumem pa tudi nekatere z njim povezane frustracije (kot je znatno počasnejši čas razvoja, ker je treba vedno najprej popraviti napačen test, potem pa še napačen program).
Smurf ::
@jype imas cisto prav (sej jaz sem to mislil z CIjem), pri nas taki testi laufajo 24/7 (commitana koda se sproti testira).
@U2ros odgovor ni trivialen. Verjetno je odvisno od zahtevnosti programa, stevilu developerjev. Oz. najbolj preprosto odvisno, koliko ze sedaj porabis za debagiranje (in kaksen je trend). Jaz osebno se nekega bolj resnega refactoringa ne upam delati brez unit testov (oz. ce ga grem delati, vem da bo pokalo nekaj casa, pa ce se tako pazim).
@U2ros odgovor ni trivialen. Verjetno je odvisno od zahtevnosti programa, stevilu developerjev. Oz. najbolj preprosto odvisno, koliko ze sedaj porabis za debagiranje (in kaksen je trend). Jaz osebno se nekega bolj resnega refactoringa ne upam delati brez unit testov (oz. ce ga grem delati, vem da bo pokalo nekaj casa, pa ce se tako pazim).
U2ros ::
Če prav razumem, integration testi bi recimo pokrivali testiranje programa, ki medsebojno združuje vec modulov katerih posamezni deli so že unit testirani. Mimogrede, anekdota od danes. Za navigacijo imam spisan softwer, ki iz gnss sprejemnika jemlje position solution (skupek trenutnega polozaja, gps časa in še nekaj drugih parametrov). Program je do danes delal bp, danes pa se je takoj po zagonu sesuval. Vzrok je bil v tem, da je bil datum zapisan kot 1022017, torej dan brez vodilne ničle kar je povzrocilo crash pri parsanju datuma. Če bi za rutino ki to počne imel narejene temeljite unit teste, bi to najbrž imel že rešeno. Bizarno je pa bilo, da smo softwer uporabljali vsaj 2 leti, a nikoli na dan ki je po zaporedni številki v mesecu manjši od 10 :) o takih sprotnih bugfixih govorim hehe
Ja, razumem. Recimo pa se malo provokativno podvprasanje. Ali bi bili testi ena od stvari, ki bi jo brisali iz todo liste, ce bi bila od tega odvisno dokoncanje projekta v doglednem roku?
Ja, razumem. Recimo pa se malo provokativno podvprasanje. Ali bi bili testi ena od stvari, ki bi jo brisali iz todo liste, ce bi bila od tega odvisno dokoncanje projekta v doglednem roku?
Zgodovina sprememb…
- spremenilo: U2ros ()
Mavrik ::
Ne razumem tega zadnjega vprašanja - pri nas so testi tako integralen del procesa, da nekako ni izbire "ali". Vsak nov kos kode / popravek se spiše tako, da je funkcionalnost pokrita s testom. Vsak bug fix se začne tako da se spiše test in potem popravi bug. Če CI ne da zelene kljukice, se stvari ne mergajo. Master ima vedno vse teste zelene in je kot tak vedno pripravljen za nujni deploy in release. (Temu veliko ljudi pravi t.i. continious delivery). Zdaj če so testi "unit" ali "integration" je to samo stvar semantike, pomembno je da
1.) Stestirajo glavno funkcionalnost da tebi ni treba vedno znova
2.) Preizkusijo čimveč robnih pogojev
3.) Zagotovijo da se hrošči ne ponavljajo
Če more za to biti za en class unit test, za drugi pa integration test... koga briga? :)
Razlika je v tem da na teste ne gledamo kot nekaj ločenga in ni izbira med "popravi drugi bug ali napiši test", ampak je v "popravi bug" sekvenci test obvezen. Takole zgleda recimo potem PR na GitHubu:
Izkaže da ko enkrat imaš tole pod kontrolo, dejansko razvijaš HITREJE, ker se ti koda neha podirati pod nogami in lahko potem jo hitro prepisuješ, popravljaš in ponavljaš.
Kar se pa rokov tiče - 99.99999999% vseh projetkov v ITju ni kritičnih in zamudijo rok in se nihče ne sekira. To pumpanje z roki je samo posledica slabih managerjev, ki namerno ali nenamerno držijo panično klimo v firmi. Je pa res da trenutno sam postavljam roke, tako da nam je tudi ta pritisk precej izginil.
1.) Stestirajo glavno funkcionalnost da tebi ni treba vedno znova
2.) Preizkusijo čimveč robnih pogojev
3.) Zagotovijo da se hrošči ne ponavljajo
Če more za to biti za en class unit test, za drugi pa integration test... koga briga? :)
Razlika je v tem da na teste ne gledamo kot nekaj ločenga in ni izbira med "popravi drugi bug ali napiši test", ampak je v "popravi bug" sekvenci test obvezen. Takole zgleda recimo potem PR na GitHubu:
Izkaže da ko enkrat imaš tole pod kontrolo, dejansko razvijaš HITREJE, ker se ti koda neha podirati pod nogami in lahko potem jo hitro prepisuješ, popravljaš in ponavljaš.
Kar se pa rokov tiče - 99.99999999% vseh projetkov v ITju ni kritičnih in zamudijo rok in se nihče ne sekira. To pumpanje z roki je samo posledica slabih managerjev, ki namerno ali nenamerno držijo panično klimo v firmi. Je pa res da trenutno sam postavljam roke, tako da nam je tudi ta pritisk precej izginil.
The truth is rarely pure and never simple.
Zgodovina sprememb…
- zavaroval slike: Mavrik ()
jype ::
Mavrik> daj če so testi "unit" ali "integration" je to samo stvar semantike
Ne drži čisto. Unit testi testirajo posamezne funkcije, integration testi pa testirajo celoten program na način, ki bolj ali manj dobro simulira okolje, v kakršnem bo program tekel, ter od programa zahteva reči, ki so podobne tistim, ki jih od programa zahtevajo odjemalci.
Unit test kliče funkcijo, ki vrne obratno vrednost in preverja, če vrne pravilne vrednosti oziroma odpove na pravilen način, integration test pa zahteva izdelavo poročila, kjer se ničla pojavi na mestu, iz katerega bo funkcija poskušala pridobiti podatek za računanje obratne vrednosti.
Ne drži čisto. Unit testi testirajo posamezne funkcije, integration testi pa testirajo celoten program na način, ki bolj ali manj dobro simulira okolje, v kakršnem bo program tekel, ter od programa zahteva reči, ki so podobne tistim, ki jih od programa zahtevajo odjemalci.
Unit test kliče funkcijo, ki vrne obratno vrednost in preverja, če vrne pravilne vrednosti oziroma odpove na pravilen način, integration test pa zahteva izdelavo poročila, kjer se ničla pojavi na mestu, iz katerega bo funkcija poskušala pridobiti podatek za računanje obratne vrednosti.
OrkAA ::
jype, to tudi ni cisto res.
Unit test: Testira en "unit" programa, torej funkcijo/metodo.
Integration test: Testira vec unitov hkrati, da vidi ce znajo sodelovat.
Functional test: Testira to kar si opisal ti. Celoten program, ki deluje v simuliranem okolju.
Je pa res, da so meje med razlicnimi nacini testiranja precej zabrisane, sploh pri manjsih programih.
Unit test: Testira en "unit" programa, torej funkcijo/metodo.
Integration test: Testira vec unitov hkrati, da vidi ce znajo sodelovat.
Functional test: Testira to kar si opisal ti. Celoten program, ki deluje v simuliranem okolju.
Je pa res, da so meje med razlicnimi nacini testiranja precej zabrisane, sploh pri manjsih programih.
Zgodovina sprememb…
- spremenil: OrkAA ()
kunigunda ::
Testerji in unit testing sta 2 razlicni stvari, ki preverjata stvari iz dveh razlicnih zornih kotov. Unit teste naj bi naceloma pisali programerji in ne testerji. Mi imamo oboje, zraven pa se continuous integration. Mogoce bi bilo smiselno omeniti se code review, ki pa si ga delajo devi med sabo (na ta nacin precej poceni eliminiras kar nekaj buggov). Ko imas enkrat program, ki v celoti zavzema nekaj miljonov vrstic, je tezko drugace sploh preziveti.
Program z nekaj miljonov vrstic ?
Smurf ::
Testerji in unit testing sta 2 razlicni stvari, ki preverjata stvari iz dveh razlicnih zornih kotov. Unit teste naj bi naceloma pisali programerji in ne testerji. Mi imamo oboje, zraven pa se continuous integration. Mogoce bi bilo smiselno omeniti se code review, ki pa si ga delajo devi med sabo (na ta nacin precej poceni eliminiras kar nekaj buggov). Ko imas enkrat program, ki v celoti zavzema nekaj miljonov vrstic, je tezko drugace sploh preziveti.
Program z nekaj miljonov vrstic ?
Pac govoril sem za svoj konkreten primer (ki ima nekje 3-4 mil. vrstic kode). Seveda pa se opisane metodologije splacajo ze pri precej manjsih programih.
Zgodovina sprememb…
- spremenil: Smurf ()
lambda ::
Testing/CI je nujen. Je pa res, da je ta obsedenost z unit testi skozi leta v okoljih kjer delam zadnja leta, precej minila. Unit testi so samo še za kritične dele sistema, vse ostalo pokrivajo integration testi. In če primerjam z iskušnjami iz preteklosti (veliko unit, malo integration testov), je to precej bolje.
kunigunda ::
Pac govoril sem za svoj konkreten primer (ki ima nekje 3-4 mil. vrstic kode). Seveda pa se opisane metodologije splacajo ze pri precej manjsih programih.
Sej me sam firbec zakaj je tok vrstic :)
Jest mam npr. kompleten web server v 50k vrsticah, SIP centralo 40k, komplet poslovanje firme 100k vrstic...
darkolord ::
Fino je, če lahko čimvečji del kode pokriješ s takšnimi ali drugačnimi testi. Pri nas imamo continuous izvajanje testov na dev mašinah, kar ti izjemno olajša razvoj, ko v real-time vidiš, da si nekaj pokvaril (in kaj), ko spremeniš vrstico kode.
Treba pa se je zavedati, da testi niso vsemogočni. Enostavni testi so trivialni, lahko pa hitro postanejo kompleksnejši kot koda, ki jo testiraš. S kompleksnostjo testa seveda narašča tudi možnost za napake v testih.
Na koncu to pomeni, da rdeča kljukica označuje, da stvar definitivno ne dela; zelena kljukica pa ne pomeni, da stvar dejansko dela, ampak da so se le testi uspešno izvedli.
Treba pa se je zavedati, da testi niso vsemogočni. Enostavni testi so trivialni, lahko pa hitro postanejo kompleksnejši kot koda, ki jo testiraš. S kompleksnostjo testa seveda narašča tudi možnost za napake v testih.
Na koncu to pomeni, da rdeča kljukica označuje, da stvar definitivno ne dela; zelena kljukica pa ne pomeni, da stvar dejansko dela, ampak da so se le testi uspešno izvedli.
Zgodovina sprememb…
- spremenilo: darkolord ()
sebastjan28 ::
Jaz sem jih vedno poskušal uporabljati, kakor je bilo le mogoče. Niti ne toliko zaradi testiranja samega, temveč predvsem zato, ker te silijo, da problem dobro najprej v glavi/papirju analiziraš in razumeš. Pa tudi končna koda je precej bolj transpšarentna in "čista". Seveda pa niso vseemogočni.
-Njihova dodana vrednost uporabnikom in managementu(še posebej takim, ki ni nikoli nič razvijali) ni takoj vidna.
-Ogromno je tudi razvijalcev, ki jih ne bodo hoteli pisati in žal jih tudi ne bodo popravili, če bodo "polomili".
-Pripraviti dobre teste navadno traja več časa, kakor pa napisati končno kodo. Tudi število vrstic je večje,...
-Tudi testi imajo lahko napake. Testi, ki testirajo napačno stvar, so ena najbolj nadležnih stvari v applikaciji,..
pa še nekaj. Podobno kakor za kodo lahko pišemo "lepe" in "zelo grde" unit teste. Na dolgi rok zadnjih nikakor ni dobro imeti - bolje nobenih unit testov sploh!
-Njihova dodana vrednost uporabnikom in managementu(še posebej takim, ki ni nikoli nič razvijali) ni takoj vidna.
-Ogromno je tudi razvijalcev, ki jih ne bodo hoteli pisati in žal jih tudi ne bodo popravili, če bodo "polomili".
-Pripraviti dobre teste navadno traja več časa, kakor pa napisati končno kodo. Tudi število vrstic je večje,...
-Tudi testi imajo lahko napake. Testi, ki testirajo napačno stvar, so ena najbolj nadležnih stvari v applikaciji,..
pa še nekaj. Podobno kakor za kodo lahko pišemo "lepe" in "zelo grde" unit teste. Na dolgi rok zadnjih nikakor ni dobro imeti - bolje nobenih unit testov sploh!
Zgodovina sprememb…
- spremenil: sebastjan28 ()
mojca ::
Kateri unit testing framework pa uporabljate za C++? Pravkar zbiram in na slepo razmišljam o https://github.com/google/googletest
Mavrik ::
Kateri unit testing framework pa uporabljate za C++? Pravkar zbiram in na slepo razmišljam o https://github.com/google/googletest
Mi uporabljamo glih tale googletest in smo z njim zelo zadovoljni - bp dela na Windows, Linux, macOS, iOS in Androidu ter izvozi podatke v Jenkins kompatibilien XML file.
Ker ti zgradijo en sam binary, lahko na test tudi zelo zlahka priklopiš kakršenkoli profiler (Instruments, valgrind, itd.) in tako testiraš hitrost / dostop do spomina za en sam test.
The truth is rarely pure and never simple.
Zgodovina sprememb…
- spremenil: Mavrik ()
mn ::
Kateri unit testing framework pa uporabljate za C++? Pravkar zbiram in na slepo razmišljam o https://github.com/google/googletest
Catch ( https://github.com/philsquared/Catch )
Je header only in lightweight vendar ima manj featurjev kot googletest.
Smurf ::
Kateri unit testing framework pa uporabljate za C++? Pravkar zbiram in na slepo razmišljam o https://github.com/google/googletest
Mi uporabljamo glih tale googletest in smo z njim zelo zadovoljni - bp dela na Windows, Linux, macOS, iOS in Androidu ter izvozi podatke v Jenkins kompatibilien XML file.
Ker ti zgradijo en sam binary, lahko na test tudi zelo zlahka priklopiš kakršenkoli profiler (Instruments, valgrind, itd.) in tako testiraš hitrost / dostop do spomina za en sam test.
+1
Tudi mi uporabljamo googletest, z izvozom v Jenkins.
kingsix ::
Vsak, ki pride v neko podjetje nekako nadaljuje prakso, ki se je izvajala prej oz. se izvaja z strani drugih. Če nihče nikoli ni izvajal TDD, potem na sami firmi tudi ti verjetno ne boš.
TDD je bil nekaj časa zelo opevan kot oh in sploh, ampak se je to počasi začelo spreminjat. Tudi meni se zdi,da TDD ni oh in sploh. Odvisno od projekta, ampak velikokrat se zgodi, da se razvijalci nato več ukvarjajo z popravljanjem samih testov kot kode.
Ko sem prišel na trenutno firmo niso imel initi enega unit testa, kljub temu, da so aplikacije zahtevne in je v igri veliko denarja (gre za platformo za športne stave). Ampak zadeva je delala in nihče ni diral. Mene so najeli, da zadeve optimiziram/refaktoriram - in tukaj unit testi pridejo zares prav. Niti v sanjah ne bi šel tega delat brez testov.
Drugače pa imamo sedaj unit teste za vse kritične funkcionalnosti (izračuni, knjiženje etc.) in vsak petek imamo "test day", kjer vsi razvijalci testiramo taske, ki niso bili naši. Ko je vse stestirano, pa še se naredijo code reviewi z strani mene oz. če je koda moja z strani sodelavca. Pred releaseom kakšnih večjih sprememb še se stestira celotna app, po testnem planu. Nekega kritičnega buga ni bilo že lep čas, tako, da je tole za nas popolnoma dovolj.
TDD je bil nekaj časa zelo opevan kot oh in sploh, ampak se je to počasi začelo spreminjat. Tudi meni se zdi,da TDD ni oh in sploh. Odvisno od projekta, ampak velikokrat se zgodi, da se razvijalci nato več ukvarjajo z popravljanjem samih testov kot kode.
Ko sem prišel na trenutno firmo niso imel initi enega unit testa, kljub temu, da so aplikacije zahtevne in je v igri veliko denarja (gre za platformo za športne stave). Ampak zadeva je delala in nihče ni diral. Mene so najeli, da zadeve optimiziram/refaktoriram - in tukaj unit testi pridejo zares prav. Niti v sanjah ne bi šel tega delat brez testov.
Drugače pa imamo sedaj unit teste za vse kritične funkcionalnosti (izračuni, knjiženje etc.) in vsak petek imamo "test day", kjer vsi razvijalci testiramo taske, ki niso bili naši. Ko je vse stestirano, pa še se naredijo code reviewi z strani mene oz. če je koda moja z strani sodelavca. Pred releaseom kakšnih večjih sprememb še se stestira celotna app, po testnem planu. Nekega kritičnega buga ni bilo že lep čas, tako, da je tole za nas popolnoma dovolj.
Zgodovina sprememb…
- spremenilo: kingsix ()
mojca ::
kingsix: kaj pa, če si edini developer v firmi ali pa vsi ostali delajo v drugem programskem jeziku? Tvoja zgodba je točno protiprimer izjave v prvem stavku 
.
. U2ros ::
Še eno vprašanje iz te tematike, ki se bolj konkretno nanaša na python. Ali drži, da bi načeloma modul unittest brez problema uporabljal za kakršnekoli teste, tudi integration teste, ker ta zgolj zagotavlja infrastrukturo za testiranje, nima pa nobenih predpostavk ali zahtev kaj konkretno naj bi dejansko testiral, posamezno funkcijo ali interakcijo med tvojimi moduli in nekimi external dependancyi.
Pa če bo koga zanimalo, 2 linka, ki mislim, da zelo dobro prikazujeta point testov in kako se jih lotit:
http://www.diveintopython3.net/unit-tes...
http://enterprisecraftsmanship.com/2015...
Pa če bo koga zanimalo, 2 linka, ki mislim, da zelo dobro prikazujeta point testov in kako se jih lotit:
http://www.diveintopython3.net/unit-tes...
http://enterprisecraftsmanship.com/2015...
Tr0n ::
Za neko resno delo, rabis se kaj vec.
Unit test kot osnova. Ko napises neko critical funkcijo/class/whatever, takoj se unit test zraven.
Preden komitas, developer vedno naredi se hiter smoke test funkcionalnosti, ki jo je dodal. Pazi, da ne pokvari builda.
Continuous integration, ki seveda pozene unit in ostale avtomatske teste ter naredi auto deploy za testerje, ce je vse vredu.
Testerji naredijo se en smoke test nad celotnim produktom in potestirajo bug fixe, gredo skozi test case-e etc.
Unit test kot osnova. Ko napises neko critical funkcijo/class/whatever, takoj se unit test zraven.
Preden komitas, developer vedno naredi se hiter smoke test funkcionalnosti, ki jo je dodal. Pazi, da ne pokvari builda.
Continuous integration, ki seveda pozene unit in ostale avtomatske teste ter naredi auto deploy za testerje, ce je vse vredu.
Testerji naredijo se en smoke test nad celotnim produktom in potestirajo bug fixe, gredo skozi test case-e etc.
Zgodovina sprememb…
- spremenilo: Tr0n ()
U2ros ::
Za neko resno delo, rabis se kaj vec.
Unit test kot osnova. Ko napises neko critical funkcijo/class/whatever, takoj se unit test zraven.
Preden komitas, developer vedno naredi se hiter smoke test funkcionalnosti, ki jo je dodal. Pazi, da ne pokvari builda.
Continuous integration, ki seveda pozene unit in ostale avtomatske teste ter naredi auto deploy za testerje, ce je vse vredu.
Testerji naredijo se en smoke test nad celotnim produktom in potestirajo bug fixe, gredo skozi test case-e etc.
To razumem ja, bolj me je zanimalo, če morda obstajajo namenski frameworki/libi za integration testing, kar sem morda čisto zgrešil (nisem po profesiji programer). Seveda je končni cilj avtomatizacija testov. Mimogrede, ali continus integration v praksi pomeni, da recimo ekipa devov v neko suito testov dodaja nove teste (unit, integration, karkoli je pač potrebno) skupaj z novo osnovno kodo, ki jo ti testi preverjajo, to se pa potem po nekih pravilih v dotični organizaciji commita v git ali kak drug VCS, nakar se periodično ali on demand avtomatski testi izvedejo potem pa se glede na rezultate popravi napake in gremo naprej...
... ampak ubistvu kot smo ugotovili za konkretni python modul unittest, ta se lahko uporabi za kakršnekoli teste, med drugim tudi bolj granularne unit teste.
Zgodovina sprememb…
- spremenilo: U2ros ()
ragezor ::
ce zelis lahko modul unittest uporabljas za pisanje in poganjanje testov, ki preko seleniuma kontrolirajo browser
sicer obstajajo neki frameworki, ki bi naj bili posebej namenjeni temu, ampak tudi preko unittesta deluje
torej ja, unittest modul lahko uporabljas kjer hoces. ce se ne motim je tudi Djangotov test framework izpeljan iz unittest
sicer obstajajo neki frameworki, ki bi naj bili posebej namenjeni temu, ampak tudi preko unittesta deluje
torej ja, unittest modul lahko uporabljas kjer hoces. ce se ne motim je tudi Djangotov test framework izpeljan iz unittest
brodul ::
V pythonu se naceloma uporablja 2 stacka za testiranje kode:
Za manjse projekte ali ce ze zacnes ucit je da uporabis unittest za vse teste: unit, integration, functional, system kakorkoli jih ze zelis kategorizirati.
Unittest je vgrajen v python. Teste daj vedno v mapico "tests", nikoli pa v mapo "test". To zaradi tega ker je "test" python built-in module in ni fino, da ga overridas.
Nose (nosetest) je pa test runner, ki se ga uporablja, za zbere vse teste in jih pozene. Ni nujno, da ga imas samo pride prav, ker lahko pozenes samo dolocene teste ali pa ti naredi xunit porocilo za CI.
Za bolj kompleksne projekte se pa splaca pogledat pytest knjiznico. Ta boljse dela z testnimi podatki (fixtures), je bolj fleksibilna in ima cel kup pametnih dodatnih knjiznic.
Velikokrat se zgodi, da moras med testi kaksen objekt zamenjat z laznim objektom in pri tem ti v python pride prav mock knjiznica. Ce uporabljas python3 je ze vgrajena.
Ko bos pregledal te stvari, se splaca malo poduciti, razloziti pisanje testov nadrejenim oz. kako pravilno planirati cas, da to vklucuje pisanje testov, ce se prej ta praksa ni uporabljala. Spremenil se bo najbrs tudi nacin kako pises kodo. Tipicno iz funkcij, ki klicejo funkcije v razrede, ki imajo dolocene atribute zato, da se jih da med testom brati ali na zacetku testiranja spremeniti.
- unittest + nose
- pytest
Za manjse projekte ali ce ze zacnes ucit je da uporabis unittest za vse teste: unit, integration, functional, system kakorkoli jih ze zelis kategorizirati.
Unittest je vgrajen v python. Teste daj vedno v mapico "tests", nikoli pa v mapo "test". To zaradi tega ker je "test" python built-in module in ni fino, da ga overridas.
Nose (nosetest) je pa test runner, ki se ga uporablja, za zbere vse teste in jih pozene. Ni nujno, da ga imas samo pride prav, ker lahko pozenes samo dolocene teste ali pa ti naredi xunit porocilo za CI.
Za bolj kompleksne projekte se pa splaca pogledat pytest knjiznico. Ta boljse dela z testnimi podatki (fixtures), je bolj fleksibilna in ima cel kup pametnih dodatnih knjiznic.
Velikokrat se zgodi, da moras med testi kaksen objekt zamenjat z laznim objektom in pri tem ti v python pride prav mock knjiznica. Ce uporabljas python3 je ze vgrajena.
Ko bos pregledal te stvari, se splaca malo poduciti, razloziti pisanje testov nadrejenim oz. kako pravilno planirati cas, da to vklucuje pisanje testov, ce se prej ta praksa ni uporabljala. Spremenil se bo najbrs tudi nacin kako pises kodo. Tipicno iz funkcij, ki klicejo funkcije v razrede, ki imajo dolocene atribute zato, da se jih da med testom brati ali na zacetku testiranja spremeniti.
Pretending to be a mature adult is so exhausting.
U2ros ::
@brodul
Sem seveda že bral od nose runnerja, samo nisem videl pointa (naredil sem korektne unit teste samo za en lib), zdaj pa takoj ko sem naredil še za 2 pa že vidim da je bolj praktično, še bolj mi je pa všeč da lahko sedaj določene setupe in teardowne delam na modul levelu, oziroma imam nad tem več kontrole. Hvala za tip
Sem seveda že bral od nose runnerja, samo nisem videl pointa (naredil sem korektne unit teste samo za en lib), zdaj pa takoj ko sem naredil še za 2 pa že vidim da je bolj praktično, še bolj mi je pa všeč da lahko sedaj določene setupe in teardowne delam na modul levelu, oziroma imam nad tem več kontrole. Hvala za tip
holabaluza ::
Sam sem se navadil, da unit teste pisem po sami implementaciji featurja, izjemomo v primerih, kjer se razvija javni API. Za bugfixe se pa pocasi navajam, da najprej spisem test case, ki faila zaradi buga, kasneje pa ga pofixam.
johnnyyy ::
Odvisno. Sam programiram na zelo low level nivoju (RTOS, Linux Kernel, bare-metal). Včasih sem bil pristaš unit testov, danes pa bolj prisegam na funkcionalni test na ciljni napravi oz. čim bolj podobnem okolju. Opazil sem, da za kakovostne unit teste porabim veliko časa, pa še vedno se najde kakšna malenkost, ki je ne zajamem. Zato jih uporabljam samo, kjer lahko enostavno testiram oz. imam malo številčne robne pogoje. V primeru nadgradenj, redesigna, velikih sprememb se velikokrat poslužujem "primerjalnih" testov, kjer primerjam rezultate stare stestirane kode z rezultati nove kode.
krneki0001 ::
Zanimivo, sam uporabljam vedno 3 različna okolja, imamo pa 4 okolja skupaj.
- razvojno okolje; Razvijem zadevo in jo sam stestiram z unit testi. Testiram samo narejen posamezen program ali del programa/modula.
- testno okolje; kamor odložim narejen celoten program in ga stestira nekdo drug s svojimi testi (ne morem vplivat na teste)
- predprodukcijsko okolje; Program se tja naloži, potem pa se stestira kako vpliva na ostale programe in kako ostali vplivajo nanj. Nihče ne more vplivat na testiranje, ker je kopija produkcijskega okolja in se vse izvaja po urniku obdelav. Pregledujejo pa uporabniki rezultate skupka vseh programov, če so primerljivi z željenimi rezultati.
Na koncu pa se prenese celoten narejen produkt na:
- produkcijsko okolje; tja se prenese, ko uporabniki potrdijo pravilnost izvajanja celotnega produkta.
- razvojno okolje; Razvijem zadevo in jo sam stestiram z unit testi. Testiram samo narejen posamezen program ali del programa/modula.
- testno okolje; kamor odložim narejen celoten program in ga stestira nekdo drug s svojimi testi (ne morem vplivat na teste)
- predprodukcijsko okolje; Program se tja naloži, potem pa se stestira kako vpliva na ostale programe in kako ostali vplivajo nanj. Nihče ne more vplivat na testiranje, ker je kopija produkcijskega okolja in se vse izvaja po urniku obdelav. Pregledujejo pa uporabniki rezultate skupka vseh programov, če so primerljivi z željenimi rezultati.
Na koncu pa se prenese celoten narejen produkt na:
- produkcijsko okolje; tja se prenese, ko uporabniki potrdijo pravilnost izvajanja celotnega produkta.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Python najbolj vroč programski jezik (strani: 1 2 3 )Oddelek: Novice / Ostala programska oprema | 29063 (23417) | BigWhale |
| » | Kdo je "dober" programer?Oddelek: Programiranje | 5025 (3617) | kunigunda |
| » | Kako poteka testiranje programov?Oddelek: Pomoč in nasveti | 1349 (1221) | gendale |
| » | Odkrit resen hrošč v PHP 5.3.7 (strani: 1 2 )Oddelek: Novice / Varnost | 16972 (14739) | Spura |
| » | XP - osnovni princip "extreme programminga"Oddelek: Programiranje | 1308 (1105) | fiction |