Ahoj, ja jsem o zavedeni jednotkovych testu u nas ve firme taky usiloval. Nakonec jsem to prehodnotil a chtel jsem testy na urovni komunikacniho protokolu mezi klientem a serverem. Neproslo mi to. Duvodem je zcela urcite cena projektu. Veskere automatizovane testy snizi naklady na udrzbu aplikace, ale bohuzel zvednou naklady na prvni verzi. Bohuzel zakaznika ze zacatku zajima kolik zaplati za prvni verzi. Vyssi naklady na udrzbu uz nejsou tak videt. Zakaznik si ani neni jisty jestli vubec bude dalsi verzi potrebovat, nebo chtit. Z meho pohledu by jakekoliv testy zlepsili stabilitu systemu. Z pohledu nadrizenych jsou nanic a spozdi/prodrazi vydani prvni verze.
Co povazuji za nutne pred zavedenim pouzivani automatizovaneho testovani je 1. automatizovat preklad celeho projektu 2. automatizovat rekonstrukci dat v databazi 3. automatizovat deploy aplikace Pak bych teprve zacal premyslet o tom co a jak testovat. Nejjednodussi se mi jevi zacit psat testy na urovni komunikacniho protokolu mezi klientem a serverem. Napriklad u nas se pouzivaji standardy OGC a za celou dobu vyvoje se ten protokol jen rozsiroval. Drzim palce, at dopadnete lepe jak ja! Zdenek Vrablik On 3/29/06, Daniel Holesinsky <[EMAIL PROTECTED]> wrote: > Zkusil bych rozdelit odpoved na 2 casti: > > 1) neschopnost zakaznika zadat praci: > Je vice zpusobu, jak donutit zakaznika potvrdit co chce. Vyzkousene v > nasem pripade jsou use case diagramy jako specifikace pozadavku na > aplikaci (strategicka analyza toho co zakaznik vlastne chce). Pote > nasleduje analyza procesu atd - funkcni specifikace atd.. Takze takova > modifikace UP. V pripade, ze zakaznik doopravdy poradne nevi co chce se > mi libi agilni metodiky. Proste jsou mnohem vic prizpusobene tomu, ze > zakaznik tape. Takze se proste integruje do vyvoje... Stejne tak se > osvedcuje americky :) zpusob mysleni (nefunguje? zahodit, napsat znovu, > perfekcionismus je zbytecny). Teda nevim jestli neco jako americke > mysleni existuje, akorat se clovek ze vsech knih o softwarovem vyvoji > dozvida neco takoveho :). > > 2) psani testu. Viz a 1) > Test pisu uz na pozadovanou funkcnost. Diky testu si muzu ujasnit co > vlastne chci napsat. Co se tyce usetreni casu, tak testovani funkcnosti > nekdy vypada nasledovne: maven jboss_war_only -> pockam az se war > nahraje na jboss /-> proklikam se v pozadovane fcnosti -> jestli je vse > ok, dobre. JEstli ne tak logger.debug .. nebo debug primo na Jbossu. > Jestlize zaberu cas tim, ze napisu test a ten mi projde, tak mam > teoreticky zaruceno, ze nektere chyby jsou odchyceny a testovani na > serveru muzu minimalizovat. (nemluvim o J2EE vecech co jsou vyzadovany > po JBossu ale predpokladam, ze diky architekture JBosse by se to dalo > taky otestovat). > > DH > > > >>> [EMAIL PROTECTED] 28/03/06 07:11odp. >>> > Nejake testy dopredu je urcite pekne napsat, ale nakolik to skutecne > delate v normalnim produkcnim prostredi ? Nepocitam nejake male > projekty pro sebe. > > V normalnich projektech zakaznik vetsinou poradne nevi co vlastne > chce, ale musi to bejt nasazeny do pul roku. Takze na tom zacne delat > celej tym a jeste nez je vlastne hotova analyza tak se jiz programuje, > za behu se to meni, mesic pred odevzdanim kdy ukazujete zakaznikovy > nejakej prvni malo funkcni prototyp se ukaze se to vlastne takhle moc > nechtel a to co bylo v zadani vagne specifikovano jako malej prirucni > sklad je nakonec skladove hospodarstvi na samostatnej system > (samozrejme chyba obchodniku kteri neco tak nedokonale popsaneho > zaridili). A to je realita. Takze nejake testy dopredu se moc nedaji > napsat protoze na zacatku vypada ze fukce fce(a,b) ma vratit soucet > tech cisel, ale nakonci vraci soucin, takze by jste v prubehu museli > ty testy desetkrat prepisovat. > A to ze neco nekde nefunguje uplne dobre protoze to neproslo dobrejma > testama vadi vetsinou zakaznikovy daleko mene nez to ze jste nestihli > termin o mesic. (samozrejme nepocitam ze delate program pro banku, i > kdyz tam bych mohl taky vypravet co se clovek vsechno nedovi). > Mam pocit ze heslem dnesniho programovani je strej vtip kterej se > vypravel o prvnim chybovem pentiu: > Kolik je 2+3 ? > Pentium: 6 > To ale neni pravda, vysledek je 5 > Pentium: to nevadi, ale je to rychle. >
