nemec Posted March 18, 2012 Report Share Posted March 18, 2012 Kā notiek ilgtermiņa projektu izstrāde jūsu uzņēmumos? Piemēram, draugiem.lv projekts, kas nekad nebeigsies un to būs jātaisa, jālabo, jāattīsta utt. Aprakstiet visu projekta izstrādes posmu. Kā tiek taisīti hotfix, versijas (successfull git branch model)? Vai tiek lietots Test Driven Development? Kā tiek iesaistīti jauni programmētāji? Quote Link to comment Share on other sites More sharing options...
foxsk8 Posted March 19, 2012 Report Share Posted March 19, 2012 Vispirms lai veidotu lielus projektus ir jāizstrādā kārtīgs biznesa plāns, modulis, jāsaliek viss uz papīra jau projekta izstrādes sākumā. Šis plāns vienmēr var kalpot kā ieskats tam, vai izstrāde un veiktie projekta darbi atbilst sākumā uzstādītiem mērķiem. Pirms lielu projektu sākšanas, ir jāparedz pareiza naudas plūsma, izlietojums, investīcijas, utt.. jo bieži vien ir tā, ka projekts tiek izveidots, bet bieži vien vajadzīgi kaut kādi uzlabojumi, jaunas iespējas, kas nebija minētas un domātas pašā sākumā, bet reāli bieži vien daudzi aizmirst to, ka jebkurai papildus lietai, idejai ir vajadzīgi jauni, jeb papildus resursi, lai ideju spētu īstenot dzīvē. Ja ir šis divas lietas jau izdomātas līdz galam pašā sākumā, neradīsies lielas problēmas projektu attīstības gaita. Par pašu programmēšanas daļu, sākumā arī jāizvērtē visi plusi un mīnusi, jāizvēlās darba vides platforma, programmēšanas valoda, jāveic neliela analīze, vai ilgtermiņā būs programmētāji, kurus bez grūtībām varēs jebkurā laikā pieslēgt jau pie esošā projekta, jo bieži vien ir tā, ka kāds "gudrītis" izstrādā platformu, kuru reāli pārējie neviens neizprot, līdz ar to bieži vien sanāk visu pārveidot tā, lai arī citi spētu strādāt un attīstīt projektu tālāk. Tā ir visai izteikta problēma lieliem un sarežģītiem projektiem. Pārējais jau ir izstrādes sīkumi, SVN, Testa vides, utt... par to es šājā gadījumā uztrauktos vismazāk. Šis bija neliels tāds izstrādes posma apraksta sākums, jo neviens domāju par velti tev neveidos un nestāstīts "Aprakstiet visu projekta izstrādes posmu." Jeb vārdu sakot, neveidos nezināma projekta specifikāciju. Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 19, 2012 Report Share Posted March 19, 2012 (edited) Šī brīža projektā tiek izmantots Git+GitHub, testa/build Jenkins serveris ar instancēm katram izstrādātājam. Parastā izstrāde: Pastāv kopējais repozitārijs, kuru izstrādātāji forko. Izstrādā fīču / sataisa bugu. Parasti jaunai fīčai uzreiz arī uztaisa unit testu, retāk - selenium testu. Nokomito savā repo un Jenkins sabūvē versiju uz testa servera, palaiž testus (unittesti + selenium testi). Ja testos viss ok, tad taisa pull request, kur piemin attiecīgo ticketu un linku uz build rezultātu. Tālāk ir 2 team leadi, kas var kodu samergot ar kompānijas repo, nokomittot un attiecīgi tiek palaists build uz galvenās testa instances. Ja kaut kas pull requestā nepatīk, tad nemergo, bet pieraksta komentārus kodu. Jaunas versijas + patchi: Normāli tiek izmantots master zars, bet, liekot produkcijā versiju, tai tiek uztaisīts savs zars. Ja ir kaut kādas atsevišķas lietas, kas jāsataisa produkcijas versijā, nesavienojot ar galveno zaru, tad izstrādātāji attiecīgi strādā ar šo zaru. TDD: Netiek lietots. Mans personiskais viedoklis - labiem izstrādātājiem tam nav būtiski labumu, bet, iespējams, tā saku tikai tāpēc, ka pašam nav bijusi prakse. Jaunu izstrādātāju iesaiste: Darbu sāk ar forku GitHubā. Tur ir arī readme fails, kur aprakstīts, kā uzstādīt vidi pie sevis. Parasti pirmie uzdevumi ir kādi mazi bugi vai citi vienkārši taski. Tā kā kopējais process ir ar pull request, tad viņu kodu uzreiz var arī pārbaudīt pirms pievienot galvenajam repo. Edited March 19, 2012 by edgarsj Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted March 19, 2012 Report Share Posted March 19, 2012 Teoriju vari palasīt grāmatās, PHP projektu praksē ir tā, ka pirmā versija ir šausmas, otrā versija ir pirmais mēģinājums tikt pāri šausmām, trešajā versijā visi jau saprot, kas ir Framework, versiju kontrole un procesu vadība, ceturtajā versijā jau kaut kas jēdzīgs sanāk un cilvēki uz darbu iet ražot, nevis lipināt un workaroundot. Tas tā, īsumā. Liela, laba projekta pazīme ir projekta vadītājs, galvenais programmētājs, kurš nosaka toni, versiju kontroles sistēma, uzdevumu vadības sistēma, dokumentācija, iknedēļas sanāksmes.. arī īsumā. Parasti sākumposmā daudzi komponenti iztrūkst un projekts vairāk vai mazāk tiek balstīts uz veiksmes faktoru tādā ziņā, ka paveicas, ja programmētājs ar to tiek galā, bet gadās, ka gads(-i) iztērēti un rezultāts ir nekāds, procesā iesaistītie arī tikpat dumji, cik bijuši, tik palikuši. edgarsj aprakstītais variants ir tāds jau diezgan labs. Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 19, 2012 Report Share Posted March 19, 2012 Pie iepriekšējā pavisam aizmirstu aprakstīt ticketing sistēmu + izmantoto scrum metodoloģiju. Ja ir interese, jautājiet. Quote Link to comment Share on other sites More sharing options...
Kaklz Posted March 19, 2012 Report Share Posted March 19, 2012 Tīri intereses pēc pāris jautājumi par Scrum un projektu: *) cik cilvēku ir komandā? *) cik garš jūsu gadījumā ir sprints? *) Jums produkta relīzes uz produkcijas vidi notiek tikai sprinta beigās, kad teorētiski viss sprinta backlog ir pieveikts, vai arī relīzes uz produkcijas vidi notiek neatkarīgi no sprinta sākuma/beigām? Teiksim viena sprinta laikā ir iespējama arī situācija, ka 2 nedēļu laikā ir piemēram 10 relīzes uz produkcijas vidi? *) ko darīt ar steidzamajiem darbiem? Teiksim sprints ir 2 nedēļas, sprinta backlog ir sakrāmēts un tad tu izdomā, ka ir kāda supersvarīga fīča, kuru vajadzētu ieviest ASAP. Vienkārši metam iekšā sprinta backlog un upurējam kaut ko citu? Ko darīt, ja šādas situācijas kļūst regulāras? *) vai jūs veicat ikdienas kopā sanākšanas ar mikro-atskaitēm par padarīto / plānoto? Ja jā, tad vai nav tā, ka daļu no programmētājiem tas kaut kādā veidā kaitina, viņi to uzskata par nevajadzīgu? Ar domu - "es jau 3. dienu kodēju šito un liec tu mani mierā, ļauj strādāt." *) Kas ir tie rīki, kā jūs pārvaldat scrum procesu? Kādi web bāzēti rīki? Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 20, 2012 Report Share Posted March 20, 2012 Tīri intereses pēc pāris jautājumi par Scrum un projektu: Piezīme, mūsu konkrētajā gadījumā visi strādā attālināti, tāpēc nav tīrs scrum un dažas lietas normālā gadījumā būtu citādāk. *) cik cilvēku ir komandā? izstrādātāji ir 7-8 *) cik garš jūsu gadījumā ir sprints? 1 nedēļa, bet domāju, ka klātienē strādājot būtu 2as. 1 nedēļa palīdz labāk turēt roku uz pulsa. *) Jums produkta relīzes uz produkcijas vidi notiek tikai sprinta beigās, kad teorētiski viss sprinta backlog ir pieveikts, vai arī relīzes uz produkcijas vidi notiek neatkarīgi no sprinta sākuma/beigām? Teiksim viena sprinta laikā ir iespējama arī situācija, ka 2 nedēļu laikā ir piemēram 10 relīzes uz produkcijas vidi? Relīzes uz produkcijas vidi parasti ir neatkarīgas no sprintiem. Normālā gadījumā ir aptuveni reizi mēnesī. Toties uzreiz pēc tam bieži vien nākas taisīt patch relīzes. Tāda dzīve. QA nav stiprākais. *) ko darīt ar steidzamajiem darbiem? Teiksim sprints ir 2 nedēļas, sprinta backlog ir sakrāmēts un tad tu izdomā, ka ir kāda supersvarīga fīča, kuru vajadzētu ieviest ASAP. Vienkārši metam iekšā sprinta backlog un upurējam kaut ko citu? Ko darīt, ja šādas situācijas kļūst regulāras? Metam iekšā. Parasti tie ir bugi, tāpēc saprotams, ka vajag. Godīgi sakot, nav liela saspringuma par to, vai sprinta laikā izdara plānoto. Saspringums parādās, ja ir mazs t.s. velocity pāris sprintus pēc kārtas. *) vai jūs veicat ikdienas kopā sanākšanas ar mikro-atskaitēm par padarīto / plānoto? Ja jā, tad vai nav tā, ka daļu no programmētājiem tas kaut kādā veidā kaitina, viņi to uzskata par nevajadzīgu? Ar domu - "es jau 3. dienu kodēju šito un liec tu mani mierā, ļauj strādāt." Veicam. Ja ir, kas strādā pie lielās fīčas, tad vadītājs parasti jautā, kā iet ar to fīču. Normāli ir, ja pastāsta progresu, problēmas. Gadījumā, ja kas ievelkas, uzreiz arī palūdz, lai kāds cits arī paskatās un palīdz risināt. Vienam savā nodabā jau viegli uzsēsties uz kaut ko. *) Kas ir tie rīki, kā jūs pārvaldat scrum procesu? Kādi web bāzēti rīki? Ticketing sistēma - Pivotal Tracker. Ar jaunām fīčām darba process aptuveni tā: Produkta owneris (ļoti retos gadījumos kāds cits) uzraksta aptuveni vajadzīgo, ieliek Icelogā, pēc tam pats vai ar team lead palīdzību nedaudz noprecizē, pieliek label: estimate. Iknedēļas lielajā plānošanas sanāksmē (izmantojam webex) komanda kopā piešķir estimate. Pārceļ uz backlog. Product owner skatās, lai backlog secība atbilstu biznesa vajadzībām. Kad izstrādātājam nav ko darīt, tad paņem ticketu no backlog (retos gadījumos tiek sadalīti iepriekš pēc uzdevuma tipa) un sāk darbu. Ja ir jautājumu / piezīmes / etc, tad komunikācija notiek komentāros pie ticketa. Ir pieredze arī ar Scrum klātienes projektā, kur bija 2 komandas ~8 un 4 cilvēki. Tur ticketu risinājums elektroniskais bija diezgan sūdīgs, bet klātienē tas viss strādā vienkāršāk. Papildus lietojām arī lapiņu līmēšanu. Tas bija iekšējais projekts un likšana produkcijā bija visnotaļ reta. Viena lieta, kas labāka par attālināto - izstrādātāji regulāri rādīja demo sevis izstrādātajām lietām nosacīti gala klientiem. Motivējoši, jo nevienam jau negribas izgāzties, neko sakarīgu neparādot. Quote Link to comment Share on other sites More sharing options...
nemec Posted March 20, 2012 Author Report Share Posted March 20, 2012 Vispirms lai veidotu lielus projektus ir jāizstrādā kārtīgs biznesa plāns, modulis, jāsaliek viss uz papīra jau projekta izstrādes sākumā. Šis plāns vienmēr var kalpot kā ieskats tam, vai izstrāde un veiktie projekta darbi atbilst sākumā uzstādītiem mērķiem. Laikam neprecīzi biju uzdevis jautājumu. Mani neinteresē kā tiek ģenerēts biezais specifikācijas plāns, bet tieši izstrāde. Vispār mēģinu izvairīties no klientiem/partneriem ar biezu plānu uz nākotni, jo esmu vairāk elastīgas izstrādes piekritējs. Ja pie manis atnāk un vēlas uztaisīt interneta veikalu ar 100 iespējām un termiņu 6 mēneši, tad es visdrīzāk atteikšos. Tajā vietā labāk uztaisīt pirmo versiju ar tikai pašām svarīgākām lietām pa nedēļu, palaist, un skatīties kādā virzienā jāattīstās. Biznesam ļoti bieži vien būs izdevīgāka pēdējā pieeja, jo: 1) ātrāk — jau pēc nedēļas varam sākt tirgot 2) lētāk — nedēļa darba maksās mazāk nekā n mēneši 3) efektīvāk — jau pēc pāris nedēļām varam sākt pelnīt Pirms lielu projektu sākšanas, ir jāparedz pareiza naudas plūsma, izlietojums, investīcijas, utt.. jo bieži vien ir tā, ka projekts tiek izveidots, bet bieži vien vajadzīgi kaut kādi uzlabojumi, jaunas iespējas, kas nebija minētas un domātas pašā sākumā, bet reāli bieži vien daudzi aizmirst to, ka jebkurai papildus lietai, idejai ir vajadzīgi jauni, jeb papildus resursi, lai ideju spētu īstenot dzīvē. Par naudu un investīcijām jādomā projekta vadītājam (uzņēmuma vadītājam). Šis bija neliels tāds izstrādes posma apraksta sākums, jo neviens domāju par velti tev neveidos un nestāstīts "Aprakstiet visu projekta izstrādes posmu." Jeb vārdu sakot, neveidos nezināma projekta specifikāciju. Es jau neprasu biznesa noslēpumus, bet gan padalīties ar izmantotām tehnoloģijām, metodoloģijām un jaunumiem. Šī brīža projektā tiek izmantots Git+GitHub, testa/build Jenkins serveris ar instancēm katram izstrādātājam. Parastā izstrāde: Pastāv kopējais repozitārijs, kuru izstrādātāji forko. Izstrādā fīču / sataisa bugu. Parasti jaunai fīčai uzreiz arī uztaisa unit testu, retāk - selenium testu. Nokomito savā repo un Jenkins sabūvē versiju uz testa servera, palaiž testus (unittesti + selenium testi). Ja testos viss ok, tad taisa pull request, kur piemin attiecīgo ticketu un linku uz build rezultātu. Tālāk ir 2 team leadi, kas var kodu samergot ar kompānijas repo, nokomittot un attiecīgi tiek palaists build uz galvenās testa instances. Ja kaut kas pull requestā nepatīk, tad nemergo, bet pieraksta komentārus kodu. Jaunas versijas + patchi: Normāli tiek izmantots master zars, bet, liekot produkcijā versiju, tai tiek uztaisīts savs zars. Ja ir kaut kādas atsevišķas lietas, kas jāsataisa produkcijas versijā, nesavienojot ar galveno zaru, tad izstrādātāji attiecīgi strādā ar šo zaru. Paldies par pirmo saturīgo atbildi. Izskatās, ka pa lielam tiek lietots šis modelis http://nvie.com/post...ranching-model/ Vai ir grūti/viegli saregulēt tādu sistēmu — projekta lasīšanu kopā, jenkins uzstādīšanu? TDD: Netiek lietots. Mans personiskais viedoklis - labiem izstrādātājiem tam nav būtiski labumu, bet, iespējams, tā saku tikai tāpēc, ka pašam nav bijusi prakse. Atzīšos, ka man arī maz pieredzes. Tā kā rakstam testus sākumā, tad pats lielākais ieguvums ir, ka viss kods tiek pārklāts ar testiem. No tā izriet, ka arī paša koda ir mazāk, jo kods rakstās tikai lai apmierinātu testus. Un parasti pat nevajag kodu skatīties, bet pietiek vien atvērt testus, lai saprastu kas tur notiek. Un protams lielāka drošība, ja vairāk testu. Jaunu izstrādātāju iesaiste: Darbu sāk ar forku GitHubā. Tur ir arī readme fails, kur aprakstīts, kā uzstādīt vidi pie sevis. Parasti pirmie uzdevumi ir kādi mazi bugi vai citi vienkārši taski. Tā kā kopējais process ir ar pull request, tad viņu kodu uzreiz var arī pārbaudīt pirms pievienot galvenajam repo. Kāpēc netiek ļauts jauniem speciālistiem labot arī kādas galvenās lietas? Ar to ir kāda slikta pieredze? Jo, ja tiek izmantoti daudz testu, tad it kā nevajadzētu rasties dižām problēmām :) Teoriju vari palasīt grāmatās, PHP projektu praksē ir tā, ka pirmā versija ir šausmas, otrā versija ir pirmais mēģinājums tikt pāri šausmām, trešajā versijā visi jau saprot, kas ir Framework, versiju kontrole un procesu vadība, ceturtajā versijā jau kaut kas jēdzīgs sanāk un cilvēki uz darbu iet ražot, nevis lipināt un workaroundot. Tas tā, īsumā. Liela, laba projekta pazīme ir projekta vadītājs, galvenais programmētājs, kurš nosaka toni, versiju kontroles sistēma, uzdevumu vadības sistēma, dokumentācija, iknedēļas sanāksmes.. arī īsumā. Parasti sākumposmā daudzi komponenti iztrūkst un projekts vairāk vai mazāk tiek balstīts uz veiksmes faktoru tādā ziņā, ka paveicas, ja programmētājs ar to tiek galā, bet gadās, ka gads(-i) iztērēti un rezultāts ir nekāds, procesā iesaistītie arī tikpat dumji, cik bijuši, tik palikuši. edgarsj aprakstītais variants ir tāds jau diezgan labs. Nepiekritīšu, ka laba projekta pazīme ir kaut kādi vadītāji vai programmētāji. Ir uzņēmumi, kur vispār nav nekādu vadītāju un galveno programmētāju. Visi programmētāji ir vienlīdzīgi un var taisīt jebkuru feature/bug/hotfix. Tam ir savas priekšrocības un daži mīnusi. Laba projekta pazīme ir: 1) cik ātri spēj iekļauties jauni kolēģi (tas pats būtu, tikai otrādi — cik sāpīgi ir darbinieku aiziešana) 2) cik ātri tiek ieviestas jaunas iespējas — produkta attīstība 3) kā strādā paša programma — vai nav viss caurumos 4) kā un cik ātri tiek taisīti ātruzlabojumi (hotfix) Lai šo panākt, tad ir daudz rīku un metodoloģiju. Tieši tas mani arī interesē. Pie iepriekšējā pavisam aizmirstu aprakstīt ticketing sistēmu + izmantoto scrum metodoloģiju. Ja ir interese, jautājiet. Vai scrum metodoloģiju lietojāt uzreiz vai pārgājāt no kādas citas? Ja nav noslēpums, tad kas tas par projektu? Vai jūs taisāt vienu projektu, vai arī tie ir vairāki? Tīri intereses pēc pāris jautājumi par Scrum un projektu ......... Jautātās problēmas ir draugiem.lv kolektīvā? :) Quote Link to comment Share on other sites More sharing options...
Kaklz Posted March 20, 2012 Report Share Posted March 20, 2012 Jautātās problēmas ir draugiem.lv kolektīvā? :) Tā kā pagājušajā nedēļas nogalē apmeklēju Agile Riga Day 2012, tad tīri intereses pēc pajautāju arī par reālās dzīves situāciju ar Scrum izstrādi. Tā kā man nav pieredzes ar formālu Scrum procesu, tad jautājumi bija tīri no sērijas "es zinu, kā tiek darīts pie mums, es zinu teoriju, bet kā tas reāli notiek uzņēmumā, kas seko šim procesam?". Mums nav ieviests formāls Scrum vai kāds cits no Agile procesiem, taču lielos vilcienos darbs mums norit visai tuvu šiem procesiem - backlog glabājas BaseCamp, ir regulāras koda relīzes uz produkcijas vidi - bieži vien pat n reizes dienā, ne tikai bugfix, bet arī jaunas fīčas. Mums nav konkrēti definētu sprinta periodu, tāpat mums nav daily standup meeting un vēl pāris citas procesu raksturojošas lietas. Pie katra jauna izstrādes procesa ieviešanas var sagaidīt kaut kādu programmētāju pretreakciju un manuprāt tas ir tikai normāli. Ja programmētājs nav radis ik dienu stāstīt un rādīt padarīto, tad pretreakcija noteikti būs. Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 20, 2012 Report Share Posted March 20, 2012 (edited) Izskatās, ka pa lielam tiek lietots šis modelis http://nvie.com/post...ranching-model/ Vai ir grūti/viegli saregulēt tādu sistēmu — projekta lasīšanu kopā, jenkins uzstādīšanu? Par modeli - tā arī ir, jā. Jenkins + automatizēti buildi ir vienkārši. Tāpēc fui pē visiem ar palieliem projektiem bez normāla Continuous Integration rīka. Projekta lasīšana kopā - vienkārši, bet manuāls darbs. Bieži vien gadās, ka vienam cilvēkam diena aiziet, integrējot pārējo sastrādāto. Kāpēc netiek ļauts jauniem speciālistiem labot arī kādas galvenās lietas? Ar to ir kāda slikta pieredze? Jo, ja tiek izmantoti daudz testu, tad it kā nevajadzētu rasties dižām problēmām :) Nav tā, ka nevar ķerties pie galveno lietu labošanas. Vienkārši efektīvāk cilvēkam iemācīties, kas un kā projektā notiek, ja ir uzdevums, kur programmēšana prasa labi ja 5%, bet saprašana 95% un tas aizņem dienu vai divas, nevis mēnesi. Ātrāk var redzēt kā sanāk un palīdzēt, ja nepieciešams. Nepiekritīšu, ka laba projekta pazīme ir kaut kādi vadītāji vai programmētāji. Ir uzņēmumi, kur vispār nav nekādu vadītāju un galveno programmētāju. Visi programmētāji ir vienlīdzīgi un var taisīt jebkuru feature/bug/hotfix. Tam ir savas priekšrocības un daži mīnusi. Par programmētājiem taisnība, bet manā modelī ir kāds galvenais, kurš nodarbojas ar visa savilkšanu kopā un pārbaudi. Tā teikt, procesa uzturētājs, kas īstenībā nav nekāda privilēģija, jo visnotaļ garlaicīgi. Un kādam arī jābūt, kurš pieņem sākotnējos lēmumus par procesu utt. Ar pilnīgu demokrātiju ir grūti, jo ir jautājumi, par kuriem var strīdēties līdz bezgalībai un vienotu viedokli nepanāks. Vai scrum metodoloģiju lietojāt uzreiz vai pārgājāt no kādas citas? Ja nav noslēpums, tad kas tas par projektu? Vai jūs taisāt vienu projektu, vai arī tie ir vairāki? Izmantojām uzreiz. Patiesībā neesmu nekad bijis projektā, kurš pēkšņi ieviestu scrum. Ir parakstīts NDA. Tāds sarežģīts multitenancy SaaS web risinājums. Izmantotās tehnoloģijas - Python, Django, JQuery,MySQL, ir API mobilajai klienta aplikācijai. Viens projekts. Edited March 20, 2012 by edgarsj Quote Link to comment Share on other sites More sharing options...
spainis Posted March 20, 2012 Report Share Posted March 20, 2012 kā šādos projektos tiek īstenoti unit testi, jo visbiežāk viss balstās uz DB, un šādā gadījumā ātri vien testu izpildes ātrums strauji degradējas? Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 20, 2012 Report Share Posted March 20, 2012 kā šādos projektos tiek īstenoti unit testi, jo visbiežāk viss balstās uz DB, un šādā gadījumā ātri vien testu izpildes ātrums strauji degradējas? Labs jautājums. Var palīdzēt triki ar testu datubāzes turēšanu atmiņā. Tāpat standarta pieeja ir visu db katrreiz no jauna taisīt (, bet var jau arī ar konkrētu test db, kur testu transakcijas reverso, kas sanāk jūtami ātrāk. Mums tagad ir ap 130 unittestu, izpildes laiks ~300 sekundes uz amazon EC2 kastes, izmantojot amazon mysql servisu (neatceros kā saucās). Noteikti var optimizēt ar lokālu mysql+ramdisku. Bet gadās visādi - pirms tam atklājās, ka ir viens performances bugs, kuru pamanīja, jo unittesti izpildījās 4x ilgāk. Quote Link to comment Share on other sites More sharing options...
codez Posted March 20, 2012 Report Share Posted March 20, 2012 Viena lieta ir PHP unit testi servera pusei, bet mūsdienās mēdz būt aplikācijas, kur klienta puse ir krietni vien komplicētāka par servera pusi. Vai izmantojat unit testus klienta pusei? Quote Link to comment Share on other sites More sharing options...
edgarsj Posted March 20, 2012 Report Share Posted March 20, 2012 (edited) Viena lieta ir PHP unit testi servera pusei, bet mūsdienās mēdz būt aplikācijas, kur klienta puse ir krietni vien komplicētāka par servera pusi. Vai izmantojat unit testus klienta pusei? Drošvien lielajā teksta blāķī bija grūti pamanīt, ka izmantojam Selenium klienta puses automātiskai testēšanai. Un Python, ne PHP ;) Un ir nianse, Selenium testus laižam uz 3 pārlūkiem - Chrome, Firefox, IE8. Visi trīs kopā aizņem ap 1200 sekundes, ir kādi 40+ testi. Edited March 20, 2012 by edgarsj Quote Link to comment Share on other sites More sharing options...
nemec Posted March 20, 2012 Author Report Share Posted March 20, 2012 codez, manuprāt, vaicāja par javascript testēšanu ( http://tddjs.com/ http://sinonjs.org/ , te vēl vairāk http://stackoverflow.com/questions/300855/looking-for-a-better-javascript-unit-test-tool ) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.