Fejlesztés esetén jobbnak tartom ...

Programozás

a vacak kódot sok (coverage >90%) unit teszttel
13% (32 szavazat)
a jó minőségű kódot kevés (coverage <10%) unit teszttel
53% (135 szavazat)
Csak az eredmény érdekel.
35% (88 szavazat)
Összes szavazat: 255

( enpassant v | 2016. 12. 02., p – 09:39 )

Másképpen megfogalmazva:
Egy funkció fejlesztésénél az esetleges plusz időt:
- részletes tesztek írására jobb fordítani,
- inkább a kód javítására érdemes fordítani (review, páros programozás, ...).

Az is érdekelne, hogy van-e aki úgy gondolja, hogy ha jó minőségű kódot készítünk, akkor ha lenne is idő mindenre tesztet írni, akkor is felesleges, elég <10%-ra.

( Protezis | 2016. 12. 02., p – 18:53 )

Jó minőségű kód kevés unit teszttel: ilyen nincs, tesz nélkül nem lehet jó minőségű kódot írni egy hello worldnél kicsit is komplexebb esetben.

Egyrészről a szavazás is ellentmond ennek (eddig több, mint négyszer annyian szavaztak a másik lehetőségre).
Másrészről a tesztek csak annyit hoznak ki, hogy jól működik-e a kód (a teszt szerint) vagy sem, jobb nem lesz tőlük.

Komplexitás nem ugyanaz, mint a méret. Lehet hatalmas, sok ezer soros egy program, ami nem komplex, és lehet rövid, pár tíz soros, ami komplex.

Mert az emberek nagy része utál tesztet írni, azért. (Vagy fingja sincs, hogy hogyan kellene rendesen TDD szerint kódolni.)

Vagy túl nagy az egója/vélt tudása és azt hiszi, hogy olyan jól kódol, hogy véletlenül sem ronthat el egy másik rendszerben valamit.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, ezek biztosan nagy számban szerepelhetnek a szavazásban.

Vagy túl nagy az egója/vélt tudása és azt hiszi, hogy olyan jól kódol, hogy véletlenül sem ronthat el egy másik rendszerben valamit.

A kód felépítésén (tervezésén) nagyon sok minden függ, pl. ha a kód nagy része olyan, hogy attól nem függ semmi más sem, akkor ez a félelem nem játszik. Olyankor csak ahhoz kellhet teszt, hogy önmagában jó-e a kód. Egy nagyon egyszerű, könnyen érthető kódnál ez is felesleges lehet.

Sajnos volt olyan fejlesztőnk, aki annyira meg volt győződve, hogy a kódja hibátlan, hogy a tény, hogy le fogja valaki tesztelni a kódját felháborította.. A tesztelőkkel ennek megfelelően szarként bánt. azóta nincs velünk, 1-1 hiba viszont igen.

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

"rendesen TDD szerint kódolni" kimondom nyiltan. en nem hiszek a tdd-ben. Vegeredmenyben az erdekel, hogy azt csinalja-e a feature, amit elvarnak tole, fejlesztes kozben a folyamatot tesztelem nem az egysegeket.
Egy valamire valo fejlesztes soran 3-4 modulbol 10-20 fajl van megnyitva atlagosan. Ha ugyanennyi unit teszt is meg lenne nyitva valoszinuleg megorulnek.
Arrol nem is beszelve, hogy fejlesztes kozben elo-elo fordul, hogy ujra/at kell szervezni a kodot, tehat allhatnek neki a teszteket is atszervezni, total feleslegesen. Szoval engem szemely szerint hatraltat, megneheziti az alkotoi szabadsagomat :)
De olyan is elofordul, hogy nem magam miatt kell refaktoralni, hanem mert mondjuk 1-2 ember reviewzta a kodot, es valamit igazitani kell, vagy csak egesz egyszeruen konfliktol a ribe'z.
A fentiekbol illetve abbol, hogy a teszt irasakor meg kell probalni eltorni a kodot adodik, hogy tenyleges munka helyett olyan kod eltoresen agyalok, ami lehet, hogy nem is lesz resze a vegleges valtozatnak (vagy tdd-ben az eltores az kulon iteracio?). Ha ezt megszorzom azzal, hogy a tesztek eltekintve a ritka kiveteltol mindig terjedelmesebbek, mint az alany, sok esetben meg side effect is van bennuk amit kezelni kell, akkor vegeredmenyben (nekem) az jon ki, hogy ertekes fejlesztoi eroforrasokat emeszt fel TDD-vel fejleszteni, mikozben a vegeredmenyt egyben igyis-ugyis tesztelni kell.
Non plusz ultra, hogy az en agyamban sincs ingyen a context switch :D A fejemben van egy tobb modulon meg 3rd partyn at vezeto komplex funkcionalitas, es mielott lefejlesztenem/kiprobalnam, hogy egyaltalan mukodik-e, alljak neki micro managelni sz@ros kis egyseg teszteket.

Ahogy mi csinaljuk ("dobozos" sw kalkulalhato relese ciklussal):
Megelozo meeting(ek) soran megbeszeljuk hogyan illesztjuk be az uj funkcionalitast, milyen nagyobb egysegek kellenek bele. Architekturalis donteseket csapat szinten hozunk, viszont a konkret implementacio a feature fejlesztojere van bizva.
Beveretjuk a featuret a kodba, 1-3 ember atnezi alaposan a pull requestet, minel elobb, akar "fel keszen" is bemegy a masterre, hogy egyutt eljen a tobbi koddal.
Masteren aztan hasznalja a tobbi fejleszto, futnak integration tesztek, meg e2e tesztek, meg ui tesztek, meg a mock integratios tesztek, meg azt se tudom milyen tesztek vannak meg, nem is az en feladatom igazan :) (esetunkben nem csak a mi szoftverunket kell tesztelni, hanem az azzal telepitett hadoop clustert is).
Aztan mikor a vegehez kozeledik a fejlesztes, akkor dedikalt idoben irunk unit teszteket, hogy a kovetkezo fejleszto, nehezebben tudja eltorni a meglevo funkcionalitast, de addigra mar csak vegleges kodra kell irni teszteket, aminek az ido koltsege nyilvan toredeke annak, mintha vegig tutjgatni kellett volna minden egyes egyseget. Aztan 1-2 ember megnezi a tesztekrol keszult pull requestet.

-
Go konkurencia kezelés gyorstalpaló

Hat lehet hianyosak az ismereteim, de TDD-nel szo sincs a "lehessen"-rol, hanem kokemenyen "kell" tesztelni, sot elobb a teszt keszul el. "In test-driven development, each new feature begins with writing a test". Annak az eselye, hogy a vegen a production kod nem ugy fog mukodni, ahogy az elejen a tesztet megalmodtam igen magas.

-
Go konkurencia kezelés gyorstalpaló

Akkor szarul lett megtervezve a feladat. És igen, teszteket is karban kell tartani.

(Btw. TDD egyik nagy előnye szerintem, hogy rákényszerít, hogy előre tervezz és végiggondold a feladatot, ne menet közben fedezd fel az apróbb, de fontos részleteket.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Btw olyan nem letezik, hogy a legaprobb szinten megterevezed a feladatot, illetve letezik, kodolasnak hivjak. Amig a tervezesed nincs 100% fedesben a kodolassal, addig mindig lesznek apro (neha nagyobb) reszletek, amik implementacio kozben derulnek ki. Nalunk ha bejon egy ujabb feature requets, akkor annak altaban kell egy vegpont ami elindit egy async flow-t. Kell neki konkret flowt osszerakni, az flow lepesek neha helyi adatokat allitanak elo, neha 3rd partyval kommunikalnak. Ugyanazt a funcionalitast kell pl megvalositanunk 5 teljesen eltero cloud APIval (az egyik igy mukodik a masik meg ugy, az egyiknek kell valami parameter a masiknak nem), hasznalunk pl alul dokumentalt API-t, a kapott adatokat fel kell dolgozni, veges sok szamu hibat kell kezelni (amit mondjuk az a 20 API hivas general, amit elkuldunk egy flow alatt), stb. stb. Nem beszeltem meg arrol, hogy flow-k is hatnak egymasra (pl egy termination flow kiuti az upscale flowt), es mindent idenpotensen kell megcsinalni, hogy barmikor ujraindithato legyen barmelyik lepes. Elofordulhatnak konkurrens adatkezelesi issuek, amik papiron pl igen ritkan jonnek elo. Nem azt mondom, hogy lehetetlen teljes reszletesseggel megtervezni az egeszet, de ... beleoszulsz, mire minden kis reszletre ramesz, minden apro dolognak csainlsz POC-ot, hogy lasd pontosan hogyan mukodik. Es meg akkor is 100%, hogy elo fog jonni olyan dolog,ami kimaradt a tervezesbol. Itt bukik meg szerintem a TDD, hogy amikor elmondjuk hogyan mukodik meg mire valo, akkor jol hangzik, csak mikor egy komplex feladatot meg kell oldani, akkor ahelyett, hogy a problemat oldanad meg nekiallsz a rendszer kulonbozo pontjain fiktiv teszteket irni, meg olyan eseteken agyalni, amik lehet, hogy elo sem fognak jonni, vagy egy teljesen mas retegben kell kezelni a hibat. A tul sok teszt is hatrany. Szerintem a tesztek arra jok, hogy rogzitsek az egyseg mukodeset, es akik atirjak az adott funkciot ne tudjak az erdeti funkcionalitast elrontani, mert mar nem emlekeznek ra, vagy nem is ok irtak, igy sosem tudtak, hogy mukodik. Amig a fejleszto emlekszik a sajat kodjara (tipikusan fejlesztes kozben) addig kar megvedeni sajat magatol. A TDD sem ment fel az alol, hogy leteszteld kezzel, igen manualisan, hogy sikerult-e egyaltalan megodlani a problemat. A vegleges implementaciot a vegen toredek ido raforditasaval lehet tesztekkel lefedni.

-
Go konkurencia kezelés gyorstalpaló

En a tervezesrol beszeltem. Meg arrol milyen reszletesseggel lehet az elejen megtervezni valamit. Mert ahhoz, hogy olyan unit teszteket tudjal irni, amiket aztan nem kell tobbszor is atirni a fejlesztes alatt eloszor meg kell pontosan tervezni az egesz featuret, azutan pedig legaprobb reszletessegig a unitokat is. Ha meg nem is az irja a tesztet, aki implementalja, akkor talan meg reszletesebben kell specifikalni a legaprobb komponenseket is. Ahogy no a feladat merete meg komplexitasa exponencialisan novekszik a tesztelendo/tervezendo reszletek szama. Tehat vagy az elejen kell lefektetni mindent, vagy menet kozben mielott irjuk a unitot megirjuk a tesztet,de mivel ad-hoc fejlesztunk fennall az eselye, hogy amithez irtunk tesztet, vegul nem is lesz hasznalva, vagy nem ugy, hiszen nem egy tervet kovetunk, hanem esetileg problemat oldunk meg, garancia nelkul, hogy az lesz a vegleges megoldas. El kell donteni, hogy tervet kovetunk, vagy ad-hoc programozunk. En azt allitottam, hogy van az a komplexitas, ahol idoben es penzben nem eri meg elore mindent eltervezni, es azt is allitottam, hogy ha pedig nincs terv, akkor evolvalodik a kod, es azt is alllitom, ha evolvalodik a kod, akkor elofordulhat, hogy kidobott ido es penz tesztet irni.

-
Go konkurencia kezelés gyorstalpaló

Értem mit mondasz, ettől függetlenül én nagyon hasznosnak tartom azt a fajta feature fejlesztést, hogy először gondoljuk végig, hogy majd hogy is fogunk tesztelni. Ehhez nem KELL lefejleszteni
a teszteket (pl. simán lehet, hogy a unit tesztnek nincs is értelme, de mondjuk egy magasabb szintű tesztelésnek már igen), de ha már a kódot úgy írsz, illetve architekturát úgy tervezel, hogy akár utólag, de lehessen rá tesztet "írni" (ebben a unit tesztől az integrációson át a teljesítménytesztig minden benne van), az szerintem már bőven jó.

De a ketto kozott van egy Grand Canyon. En is utolag irok unit teszteket, oda, ahol tenyleg szukseg van ra, mert erdemi funkcionalitas van. Addig lehet, hogy tizszer is atirom az implementaciot (nem azt, amit csinal a fuggveny, hanem ahogy csinalja), mert menet kozben talalok egy egyszerubb megkozelitest, ami viszont egy kicsit mas strukturalis tervezest igenyel, mint amire eredetileg gondoltam. Senki nem mindenhato, senki nem tud mindent, viszont minden egyes ilyen atstrukturalasnal ujrairni az osszes unit tesztet, hat meg az a bizonyos loalkatresz.
--
Blog | @hron84
Üzemeltető macik

A unit test pont arra jó, hogy az implementáció megváltoztatása után meg tudod nézni, hogy a kód továbbra is az elvárt eredményt hozza-e. Ha nem tudsz egy függvény megírása előtt kitalálni hozzá egy unit testet*, akkor nincs megtervezve a függvény --> kuka.

* Vagy nevezzük akárhogy, a lényeg, hogy előre kellene tudnod, hogy X bemenetre Y kimenetet vársz. Ezt éppenséggel megnézheted manuálisan debuggolva is, csak az hülyeség. :)

Btw olyan nem letezik, hogy a legaprobb szinten megterevezed a feladatot, illetve letezik, kodolasnak hivjak

Én ugyan nem programozó vagyok, de úgy tudom, létezik olyan eljárás, hogy formális logikával elemzik / bizonyítják, hogy egy megtervezett algoritmus jó, és utána ültetik át valami programnyelvre

Azert van kulombseg egy algoritmust formalis logikaval elemezni, es akozott, hogy az alkalmazast megtervezni az utolso szogig, hogy amikor a teszteket irod implementacio nelkul, akkor a leheto legpontosabban ird meg oket, hogy implementalas kozben ne kelljen oket atalkitani meg bugtalanitani. Termeszetesen egy konkret feladatot ellato algoritmushoz leheet irni teszteteket, en sem azt mondom, hogy egyaltalan nem erdemes/kell tesztet irni. Az ilyen eseteket egyebkent is egyszerubb az alkalmazason kivul tesztelni. Tipikusan ha nincs benne side effect, es elore specifikalt mukodes van benne. Ezeket egyszerubb teszt mellett fejleszteni, de ez (alkalmazas valagatja) a legritkabb. Leggyakrabban egymassal egyutt mukodo komponensekkel dolgozunk, ami hemzseg a mozgo reszektol.

-
Go konkurencia kezelés gyorstalpaló

De ki beszélt arról, hogy az utolsó szögig meg kell tervezni egy implementációt? API-król meg folyamatokról van szó. Arra (legtöbb esetben) bőven elég tesztet írni.

Konkrét metódusra maximum akkor, ha az kellően komplex számítást végez.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

amit most mondasz az ellentmondd a TDD-nek, _amirol beszelunk_. En egy szot sem irtam apirol, es a TDD-ben sincs szo arrol, hogy csak az APIt kell tesztelni. En azt ecseteltem, hogy nem ertek egyet a TDD-vel, mert 1x1-en tul rohadt sok terhet ro a fejlesztore, pontosan azert, mert nincs megtervezve az utolso szogig, es a tervezetlen kod attervezese eseten minden attervezeskor minden egyes rohadt tesztet at kell tervezni.

Szoval el kene donteni, hogy "In test-driven development, each new feature begins with writing a test" vagy "Konkrét metódusra maximum akkor, ha az kellően komplex számítást végez" vagy most akkor ez mitol TDD?

-
Go konkurencia kezelés gyorstalpaló

nem ertek egyet a TDD-vel, mert 1x1-en tul rohadt sok terhet ro a fejlesztore, pontosan azert, mert nincs megtervezve az utolso szogig, es a tervezetlen kod attervezese eseten minden attervezeskor minden egyes rohadt tesztet at kell tervezni

Nem úgy megy ez, hogy a tesztet a követelmények alapján írja meg az ember, és aztán készít olyan kódot, hogy a teszt sikeres legyen?
Ha a követelmény nem változik, csak a programozó a fejlesztés egy pontján úgy dönt, hogy ő most áttervez valamit, akkor én azt várnám, hogy a követelmények alapján készített tesztek nem változnak.

disclaimer: nem vagyok programozó, soha sem programoztam TDD-t használva, és csak hallomásból ismerem, szóval simán lehet, hogy félreértek valamit.

"a tesztet a követelmények alapján írja meg az ember" feature request alapjan tortenik a tervezes, ami soran felallitjuk a kovetelmenyeket az egyes retegekkel szemben. Ha a tervezes elmegy addig, hogy Asd objektum qwe() metodusa x-el terjen vissza ha y-t kap bemenetul, akkor sima ugy. Nyilvan letrehozod az elso metodust, de mielott ezt megtenned megirod ra tesztet, meg az elronto tesztet, meg az osszes kombinacios teszteket, aztan megirod a metodust, es addig irod, amig minden zold nem lesz. Es ha vegeztel mesz a kovetkez metodusra. A baj ott kezdodik, ha nincsenek meg a kovetelmenyek ilyen szinten, mert modnjuk bonyolult a feature, pl 4 modult erint, 3 kulso APIval kommunikal, ezek kozul egyikhez jobb lenne, ha nem lenne dokumentacio, stb. Ilyenkor a kovetelmenyek ugy neznek ki, hogy X vegponton bekuldi a user xyz adatokt, a vegpont ello egy eventet, amit C modul elkap, meghivja a N servicet, ami szukseges adatokat tovabbkuldi az elso APInak, majd megnezzuk mi kell neki, meg, hogy mit ad vissza, lekezeljuk a hibat, a doksi szerint V-t ad vissza. A valaszt majd atkonvertaljuk B-re, es elmentjuk az adatbazisba, aztan ......... Jah es ha sikerult, akkor igy meg igy szamoljuk az arat. Lenyegeben az xyz adatok validacioja meg az arkalkulacio rogzitett olyan szinten, hogy azonnal lehet hozza mukodo tesztet irni. Amikor a fejleszto specifikalatlan reszhez er, es kovetve a TDD elveit elobb megirja a tesztet a nem letezo kovetelmenyhez, akkor vagy elsore eltalaja mit is kell implementalni vagy visszajar refaktoralni a teszteket, mert kiderul, hogy oops meg oda kell egy parameter, vagy adott adat meg nem megfelelo, azt a hibat egy teljesen masik retegben kell kezelni, a code review-n belekot a kollega, a kodelemzo visszadobta a valtozast, stb. millio okot lehet talalni a valtoztatas okara. Evolvalodik a kod, folyton valtozik, hiszen az implemetacio specifikalja a mukodest, es nem a specifikaciot implementalja.

Azt irtam, hogy bizonyos komplexitas felett nem erdemes, idoben es penzben olyan reszletesseggel leirni a kovetelmenyeket, ami alapjan elsore lehet kvazi vegleges tesztet irni, ha pedig nincsenek meg pontosan a kovetelmenyek, akkor meg nem eri meg sem idoben sem penzben teszteket irni es karban tartani bizonytalan eletciklusu dolgokhoz.

-
Go konkurencia kezelés gyorstalpaló

"En egy szot sem irtam apirol, es a TDD-ben sincs szo arrol, hogy csak az APIt kell tesztelni..."

Szerintem csak mast ertetek API alatt: amirol saxus beszel, az az osztaly API-ja, interface-e, stb. Az osztaly publikus fuggvenyei absztaktabban nezve az osztaly API-ja.

En is csak mostansag jottem ra, hogy azert nem ertettem en se a TDD lenyeget eddig, mert nem ismerek meg olyan kenyelmes megoldast arra, hogy egy osztaly APIjanak a viselkedeset teszteljuk ahelyett, hogy az implementaciot ismetelnenk mockokkal. Alapvetoen ennek az egesznek egy blackbox tesztnek kellene lennie, ahol csak annyit fogalmazunk meg, hogy milyen bemeno parameterre milyen kijovo erteket szeretnenk kapni. Es itt jon be az, hogy a tesztek javitanak a kodminosegen, hiszen ha egyszeruen akarsz tesztet irni, akkor muszaj mellekhatasok nelkuli fuggvenyeket, SRP-t es egyebeket betartani.

Egy ideje gondolkodom mar, hogy a havesomerest mintajara meg kellene oldani, hogy a unit testek egyben mockokkent is hasznalhatok legyenek. Igy rogton tobb legyet utunk egy csapasra, hiszen ha irunk unit testeket az adott osztaly fuggvenyehez, akkor azt a viselkedesmintat, amit epp "dokumentaltunk" a tesztekben lehetne arra is hasznalni, hogy "visszajatszva" adott tipusu bemenetre adott kimenetet adjon.

Ezzel elernenk, hogy a tesztjeinket igazan "blackbox" tesztekkent tudjuk leirni, absztraktan csak a lenyeget, a "contractot", az API viselkedeset, mindegy hogy hivjuk. Es akkor nem kell foglalkozni az implementacios reszletekkel, a kod ugy es annyit valtozik amennyit nem szegyell. Ez a fajta teszteles igazan refaktoralas barat, hiszen a belso implementacio valtozasa nem hat ki a tesztekre, ha a logika nem valtozik (marpedig ez a lenyege a teszteknek), illetve, ha a mockolhatosagot is belevesszuk, akkor mivel A osztaly tesztjei B osztaly mockjai, ha A osztaly tesztjeinek valtoztatasa, eltori B osztaly tesztjeit, ezzel jelezve, hogy a refaktoralas soran mi mindent tortunk epp el.

Tehat szerintem az idealis teszt, aminek van is ertelme, es konnyen kabantarthato es ertheto, es mintha alapvetoen errol is szolt volna a dolog a kezdetekben, hogy csak, es kizarolag az elvart viselkedest teszteld, ne pedig azt, hogy milyen osztalyokat hiv meg a fuggvenyed milyen sorrendben. Tehat, pl ha van egy multiplyByTwo(Int a) fuggvenyed, akkor a teszted ne az legyen, hogy assertEquals(4, multiplyByTwo(2)), hanem, hogy


Int anyInt = Matcher.anyInt()
assertEquals(anyInt * 2, multiplyByTwo(anyInt))

Az elso esetben, mikor konkret ertekeket adtal meg, akkor nem vilagos, hogy azert ment at a teszt, mert tenyleg osszeszorozta a 2-t meg a 2-t, hiszen akar ossze is adhadta volna oket, az utobbi verzioval viszont nem csak, hogy sokkal tobb tesztesetet fedunk le a randomitassal, sokkal leirobbak is vagyunk, hiszen az egeszet egybeolvasva gyakorlatilag egy API dokumentacio. "Barmilyen Inttel meghivva a multiplyByTwo fuggveny, annak az Intnek a ketszereset kell visszaadja". Ez egy elengedhetetlen feltetele annak, hogy a tesztek mockokkent is tudjanak funkcionalni.

Es ezert nagyon fontos a megfelelo tipusok hasznalata, es nem belehanyni mindent Stringekbe. Minel szukebb tipusmeghatarozassal elunk, annal descriptivebb lesz a fuggvenyunk szignaturaja is, illetve a teszjeink is leirobbak es tomorebbek lesznek. Ami datum menjen valami Datum dipusba, ami megszamlalhato vegessegu halmaz, az legyen Enum, ami pozitiv egesz, az legyen valami pozitiv egesz tipus, stb. Es igy a kollegaidat is megkimeled attol, hogy utolag ujra ki kelljen deriteni pontosan milyen ertekek is haladhatnak el a kod adott reszleteben.

"ahol csak annyit fogalmazunk meg, hogy milyen bemeno parameterre milyen kijovo erteket szeretnenk kapni" ahol ez van megfogalmazva ott nyilvan ezt kell tesztelni, es mivel ez az elvart mukodes, akar elore is meg lehet irni a tesztet. De a valosagban ez a kisebb hanyad. A valosagban olyanok vannak, hogy adott bemeneti parameterket lekuldi a konverter servicebe, ami visszaad egy objektumot, amit tovabbkuldd a dekorator komponensnek, ami meg igazit rajta, aztan perzisztalja az eredmenyt, majd elpostolja adott vegpontra, a valaszt atalakitja jsonbol, abbol kinyalazza, hogy volt-e hiba, ha hiba volt updateli az adatbazist, loggolja a hibat, visszakuldi az eredmenyt, ha pedig nem volt hiba, akkor kiszedi a resource id-t amivel gettel egy masik vegpontra, ami visszaadja a tulajdnsagait a valaminek, amit lement az adatbazisba, es ha a user kerte, hogy kapjon email ertesitest, akkor levelet kuldd, es visszater success statusszal.

-
Go konkurencia kezelés gyorstalpaló

A problema csak az, hogy ezek elmeletileg mind nagyon szep dolgok, de a legtobb esetben egy kod nem onmagaert van leirva, es nem onmagaval mukodik, hanem masokkal. A blackbox teszt csak es kziarolagosan integracios tesztkent mukodhet, unit tesztkent semmikepp, hiszen mondjuk egy internetes API kerest, ahol nincs sandbox, tehat minden keres elesben megy es fizetni is kell erte, nem fogsz blackbox unit teszttel tesztelni sohasem, vagy ha igen, akkor a kovetkezo havi szamlat a fizetesedbol vonjak. Mert tudod, a valosag ennyire gonosz is tud lenni.

Nem a TDD-vel van egyebkent alapvetoen baj, hanem azzal, hogy istenitik, pedig sok esetben inkabb csak hatraltato tenyezo. A TDD is egy olyan eszkoz, aminek megvan a maga helye es ideje, ahol nagyon jo hasznalni - de tudni kell elengedni, ha ez tobbet art a fejlesztesi folyamatnak, mint hasznal. Nem jelentheto ki egyertelmuen, hogy a nem TDD-ben vegigvitt projektek kivetel nelkul mind rosszabbak lennenek a TDD-ben vegigvitteknel. Jo eszkoz, tudni kell hasznalni - es nem szognek nezni mindent, pusztan csak mert van egy kiraly kalapacsunk.
--
Blog | @hron84
Üzemeltető macik

Na de pont az API jellegű dolgok azok amik jól tesztelhetőek: megvannak, hogy milyen bemenő paraméterre minek kell történnie.

Nekem is van egy komplexebb szabályalapú rendszerem, ami ráadásul futhat kliens oldalon és szerver oldalon. Eleinte nem volt gond, csak aztán jöttek az egyre komplexebb igények és egy idő után irreálisan megnőtt volna a fejlesztés igénye, ha nem lettek volna rá tesztek. Valóban nem álltam neki minden egyes metódust, settert, gettert tesztelni (az valóban hülyeség lett volna), hanem csak folyamatokat szimuláltam le és a végén megnéztem, hogy az elvárt eredményt adta-e, megfelelő sorrendben futottak-e az események, stb.

Leginkább akkor volt baromi nagy segítség, amikor már két-három éve megvolt a kód, nagyjából kiforrott is volt csak épp hozzá kellett még biggyeszteni olyan dolgokat, amik alapjaiban változtattak meg dolgokat. Olyankor nagyon nagy segítség volt, hogy néhány tíz másodperc alatt kiderült, hogy nem törtem-e el valamit a meglévő dolgok közül. Mert néha sikerült.

Viszont ha te a legelején azt sem tervezed meg, hogy milyen bemenetre mi az elvárt eredmény, illetve mire kell hibát dobni, akkor tulajdonképp miből is áll neked a tervezés? Nem egy-egy metódus szinten, hanem API/folyamat szinten értem a dolgot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na jah, csak ehhez nem kell TDDben fejleszteni. Ezt ugy hivjak, hogy mezei teszt iras. Megirod a tesztet ami kesobb jol jon. De TDD szerint nem irsz ugy le egy betut sem productionbe, hogy nincs ra teszt.

a tervezes kivulrol befele tortenik egy bizonyos szintig, de a TDD meg bentrol indul a unit-tol. Mivel tesztet irsz eloszor harom eset lehetseges:
- kintrol mar "be"tervezted a feladatot unit-ig, tehat a unit vegleges, ezert 1x kell ra megirni a tesztet az elejen, es implementalni kell (one-by-one mindent)
- nem jutott el unitig a tervezes, tehat nem tudod 100% pontossaggal, hogy mit fog csinalni a unit, amihez elobb irsz egy tesztet ugye, aztan ha nem azt csinalja vagy nem ugy, akkor kidobod a felesleges teszteket (ne feledd 4 egymasba agyazott if eseten van min 5 teszt eseted, mondjuk meg 4 null teszted, es meg arrol nem is beszeltunk ha side effect is van benne, szoval egy nagy rakas kodod van egy olyan metodushoz, amit epp most keszulsz kidobni) mert implementacio soran tervezted a kodot.
- elkezded lazabban venni a TDD szabalyait, es nem rogton irod a tesztet, hanem kicsit varsz, hogy kikristalyosodjon az implementacio, vagy csak bizonyos algoritmusoknak irsz tesztet, amirol ugy gondolod az fontos, de ez meg mar nem TDD

Vagy hagyod az egeszet a francba, es a vegleges implementacio mukodeset lefeded tesztekkel, 1x kell megirni oket, igy az utokor mar tesztelt koddal folytathatja a munkat.

-
Go konkurencia kezelés gyorstalpaló

Valóban nem álltam neki minden egyes metódust, settert, gettert tesztelni (az valóban hülyeség lett volna)

Ha mindent le akarsz fedni unit tesztekkel, akkor bizony minden egyes metódust, settert, gettert le kell tesztelni. Azok is módosulhatnak, eltörhetnek, illetve eleve lehetnek hibásak.

hanem csak folyamatokat szimuláltam le és a végén megnéztem, hogy az elvárt eredményt adta-e, megfelelő sorrendben futottak-e az események, stb.

Ezek szerint szinte semmilyen unit teszt nem volt, hanem csak folyamat és integrációs tesztek. (Ezt nem úgy értem, hogy ez baj lenne.)

"Ha mindent le akarsz fedni unit tesztekkel"

De miert akarnek mindent lefedni?

"Azok is módosulhatnak, eltörhetnek, illetve eleve lehetnek hibásak."

Azokat a metodusokat mostly meg csak nem is ember irja, hanem igy kattint harmat az IDE-ben, es eloall tizenot setter es husz getter. Es hacsak szintaxishiba nincs a dologban (amit meg nem a teszt, hanem a compiler/interpreter fog kiszurni), akkor ezek igy kabe sose tudnak eltorni, ha megis, akkor az alatta levo runtime tort el - amit szinten nem egy unit teszt feladata ellenorizni, hanem a runtime fejlesztoie.
--
Blog | @hron84
Üzemeltető macik

De miert akarnek mindent lefedni?

Ezt ne tőlem kérdezd, én csak arra a részre reagáltam, ha valaki a kód minden részét le szeretné fedni unit teszttel. Ebben az esetben ezeket is le kell fedni, nem lehet azon indok mögé bújni, amit itt írtál:

Azokat a metodusokat mostly meg csak nem is ember irja, hanem igy kattint harmat az IDE-ben, es eloall tizenot setter es husz getter. Es hacsak szintaxishiba nincs a dologban (amit meg nem a teszt, hanem a compiler/interpreter fog kiszurni), akkor ezek igy kabe sose tudnak eltorni, ha megis, akkor az alatta levo runtime tort el - amit szinten nem egy unit teszt feladata ellenorizni, hanem a runtime fejlesztoie.

Ezzel csak az van garantálva, hogy induláskor nem hibásak. Ha átírod az egyiket, akkor már eltörhet a kód és olyankor szólhatna a unit teszt.

Egyrészt TDD-nél praktikus, hogy ha nem ugyanaz írja a teszteket, mint aki a tényleges implementációt is végzi, különben könnyű beleesni ugyanabba a logikai hibába.

Refactorálás meg normál esetben miért kellene, hogy azzal járjon, hogy az unit teszteket különösebben meg kellene bolygatnod? Normális IDE átvezeti a módosítások.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"nem ugyanaz írja a teszteket" ammihez az kell, hogy 100% pontossaggal meg legyen minden tervezve, amit fentebb kifejtettem. for my information: amikor valaki mas irja a teszteket, implementacio nelkul, o hogyan ellenorzi, hogy amit csinalt az mukodik-e? Arra is ir tesztet? Vagy majd a masik bugfixeli mikozben implemental?

"Normális IDE átvezeti a módosítások" atnevezni sed-del is tudok ;) de a refaktoralas nem csak arrol szol, pl kimozgathatsz funkcinalitast osbe, bejohet ujabb side effect, felhivja a kollegad a figyelmedet, hogy van mar hasonlo dolog valahol mashol, kette kell bontani a funkcinalitast, bejon egy ujabb parameter. Ezeket egyik IDE sem fogja kezelni.

-
Go konkurencia kezelés gyorstalpaló

+1, így szerintem a kérdés értelmetlen. Hallottam már olyat, hogy egy trainee-t megkértek, írjon teszteket. Meg is írta, 100%-os lefedettséggel. Mindenki örült, és csodálkozott. Így néztek ki kb. a tesztek:

while(true) {
try {
if (kipörgettemMindenBemenőParamétert()) {
break;
}
underTest.fgv(bemenőParaméterPörgető());
} catch(Exception ex) {
}
assertTrue(true);
}

A szavazást úgy értettem, hogy a teszt író a képességeinek megfelelő legjobb teszt eseteket írja.
Almát almával kellene összehasonlítani a két esetben.
Tehát, ha magadra gondolsz, akkor szerinted:
1) jobb megírni a kódot az elsőre működő verzióra, majd valamennyi időt a képességeidnek megfelelő legjobb teszt esetekre fordítani,
2) jobb az első működő verziót az előzőnek megfelelő időben tovább javítani.

A két eset mindegyikénél még az is szóba jöhet, hogy egy tapasztaltabb kollega segít a tesztesetek írásánál vagy a kód jobbá tételében.
Tehát mindkét esetből próbáljuk kihozni a legjobbat.

( SkyNET | 2016. 12. 02., p – 21:22 )

A coverage egy elterjedt, de önmagában nem túl értelmes mutató (szerintem). Tapasztalati tény, hogy erős pozitív korreláció van a jó minőségű kód és a kód tesztelésre fordított erőfeszítések, incl. unit tesztek alkalmazása közt. Viszont az ilyen 90-100%-os lefedettség már _általában_ több bajjal jár, mint haszonnal, legalábbis az én tapasztalatom ez. Ésszel kell alkalmazni a unittesztelést is, szerintem a jó fejlesztő meg tudja ítélni, hogy a feladatai közül mit és milyen terjedelmben kell unittesztekkel alátámasztani a regressziók kiszűrése érdekében, és mi az ami már csak öncélként, különösebb haszon nélkül égetné a idejét.

Van benne valami.

Pl. a Go-hoz rögtön adják a teszt keretrendszert, coverage-el együtt, sőt színes-szagos HTML-ben mutatja, mely kódsorok lettek tesztelve, és melyek nem.
DE: könnyű úgy bővíteni a tesztet, hogy új ágakat is bejárjon, ÉRDEMI ELLENŐRZÉS NÉLKÜL!

Konklúzió: a teszt is kód, és az is lehet szar.

( hory v | 2016. 12. 02., p – 21:51 )

OMG. Coverage _semmit_ nem jelent. Az, hogy hany sor futott le a tesztek alatt, semmit nem jelent arra nezve, hogy tenylegesen teszteltek is.

Ami szamit, az az, hogy a _funkciok_ mekkora hanyada van lefedve automatikus tesztekkel. Es hogy mennyire alaposan (corner case, stb...)

A masik. Unit teszt arra valo, amire, egy-egy fuggvenyt tesztelni. En konkretan az integration test hive vagyok. Vagyis, a teszt futtasson egy kozel full-blown szervert, es lassuk, hogy a kliens interface-n keresztul azt kapom-e, amit varok. Es _mindent_ igy tesztelek. Mert senkit se erdekel, hogy egy fuggveny mit csinal, ha nem is azt hivja a szerver. Azt kell tesztelni, amiert csinaltad az egeszet, vagyis mindig a kliens szempontjabol.

Az első részére +1. Ami még érdekes, az mutation testing, szerintem egészen menő dolog.

A második részével ellenben nem értek egyet. Egy real-world funkció __nagyon__ összetett, és nagyonnagyon hamar megszalad a teszt-esetek száma, és azok bonyolultsága.
Pl.: ha egy weboldalon több OAuth szolgáltatón keresztül nyújtunk belépési lehetőséget, ha még sosem lépett be az user, akkor regisztráljuk, email próbálunk neki küldeni, utána beléptetjük, etc... Nagy tesztjeid lesznek, senki nem látja át őket, s ha A függvény módosul, akkor rengeteg olyan teszthez kell hozzányúlnom, ami az A függvényt ugyanúgy teszteli, de az F függvényre (teljesen más helyen) már más paraméterezéssel esne be...
A jól specifikált API, s azok rendes unit tesztje nagy áldás.
--
blogom

De az unit tesztekkel inkabb a bonyolult esetekre kell fokuszalni. Es itt jutunk vissza oda, hogy a szazalekok semmit nem jelentenek, mert a setLofasz(ujLofasz) fuggvenyeket felesleges tesztelni, ha csak egy ertekadas van benne. Viszont az ilyen fuggvenyek siman ki tudjak tenni a kod 20-30%-at is, es egybol megy a szajhuzas, hogy "miert csak 70% a coverage?".
--
Blog | @hron84
Üzemeltető macik

Szerintem elcsuszott a valaszom, hajnali egykor mar keptelen vagyok ennel tobb intelligenciat vinni ezekbe a dolgokba. Bocsi :-)

Viszont erdekes, hogy azt mondod "A jól specifikált API, s azok rendes unit tesztje nagy áldás." viszont API-t nem igazan tudsz unit tesztelni (vagy legalabbis az en fogalmaim szerinti unit tesztelni), valamilyen implementacionak muszaj mogotte lennie. Vagyis, vagy az implementaciot teszteled, es az az implementacio unit tesztje, vagy pedig az API-t, de ez innentol meg... hat a fene tudja, en integracios tesztnek hivnam.
--
Blog | @hron84
Üzemeltető macik

+1 az első részére.

Viszont, akkor nem integrációs teszteket futtatsz, hanem inkább komponenst teszteket.
https://codingjourneyman.com/tag/uncle-bob/page/2/
Jók az integrációs és komponenst tesztek, de egy unit teszt max 10 sec alatt lefut. Így gyakrabban tudod futtatni, és ellenőrizni, hogy nem rontottál-e el semmit. Plusz a unit tesztnek kéne lennie az osztály működésének a legabsztraktabb leírásának.

( vilmos.nagy | 2016. 12. 02., p – 23:02 )

A szar kódhoz valszeg szar teszt is tartozik.
Akkor inkább legyen jól olvasható kód, amit könnyen megértek...
--
blogom

( iattilagy | 2016. 12. 02., p – 23:04 )

Ha egy trágyadomb a kód, akkor hiába tudod lefutásra bírni a unit tesztet tuti lesz egy csomó olyan hiba amire nem gondoltál a tesztnél, de benne van.
Ha tesztre kevesebb idő lett fordítva a kelleténél, de a kód olvasható azzal még mindig sokkal többet lehet kezdeni, mint egy olvashatatlan de széttesztelt kóddal (kivéve assembly esetén...)

( Protezis | 2016. 12. 03., szo – 01:21 )

Lehetne elméletileg. A gyakorlat viszont azt mutatja, hogy ez sose teljesül. Hány embert meg pull requestet láttam én erre alapozva, aztán meg volt meglepetés... Mutathat nekem bárki bármilyen szupernek tűnő kódot, ha nincs hozzá minőségi teszt, akkor megy a kukába. 100+ fős projekten amikor ömlik be a szar mindenhonnan, nincs olyan, hogy "nincs hozzá teszt, de hidd el jó lesz"

Ez erre ment volna: http://hup.hu/szavazasok/20161202/fejlesztes_eseten_jobbnak_tartom#comm…
(Bocs, mobilon vagyok)

( gee v | 2016. 12. 03., szo – 02:20 )

Hogy definiálod a vacak és a jó minőségű kódot?

Ahány ember annyiféle definíció létezik. Semmi értelme definiálni, mert abból csak parttalan vitatkozás származik.
Ha mindenki a saját definíciója szerinti vacak és jó minőségű kódra gondol, akkor az eredmény a relatív kódminőségre nézve ad jó eredményt.
Ez kb. olyan, mintha azt kérdeznénk, hogy inkább a nagyon sósast tatod jobbnak vagy a nagyon sótlant.
A legtöbb ember számára mind a kettő nem túl jó, ráadásul, ami az egyiknek sós, az a másiknak sótlan, mégis ebből képet kaphatunk, hogy inkább a sótlan vagy inkább a sós ételeket fogyasztják inkább.
Mindenki a pont jó sósat szereti, ami az abszolút skálán a teljesen sótlantól, a tömény sósig terjed.

( Hevi v | 2016. 12. 03., szo – 02:46 )

Erdekes kerdes. 2.-ra szavaztam, mert ertheto kodhoz konnyu unit testet irni, de az elso eseten meg konnyebb refaktoralni. Szoval nehez kerdes :)

Szerintem is nehéz kérdés és azt gondolom, hogy gondolat ébresztő is egyben.
Sokszor találkozom olyannal, hogy általam nagy tudásúnak számító emberek azt nyilatkozzák, hogy teljesen felesleges a unit teszt.
Nagyon sokáig nem tudtam hová tenni ezeket a véleményeket, mert én is azt gondoltam, hogy a jó minőségű és mennyiségű teszt az mindenképp szükséges a jó kódhoz.
Aztán most egy példa kódon, amit írtam észrevettem, hogy nem igazán hiányzik a legtöbb részére teszt.
Természetesen a példa kód nem elsőre lett jó minőségű (legalábbis az én megítélésem szerint), hanem többszöri átdolgozás után.

Most már valóban nem tudom mire gondolsz.
Fogalmam sincs hogyan jön ide a main.
Egy függvényhez megfelelő teszt írása az időben összevethető a kód írásával, van olyan is, hogy még több is.
Egy függvényhez a bejövő paraméterek mindenféle határértékeire és ezek mindenféle kombinációjára kellene tesztelni.
Sok függvény, sok tesztesetéről van szó. Hogyan jön ide egy main függvény?

Ja, elnézést, akkor ilyennel ezek szerint még nem találkoztál. Amikor a fiatal kollégától megkérdezzük, hogy szokott
tesztelni, és a válasz az, hogy hát csinál egy main függvényt, és beleírja. Hát, mondom, ehhez képest 3 sorral többet
írna, és akkor már egy unit teszt lenne, ami a 0-hoz képest már előrelépés.

( dszakal | 2016. 12. 03., szo – 11:11 )

Tovabbmegyek: inkabb vacak kod unit tesztek nelkul, de konzisztens es logikus adatbazissal(!), mint szep kod, sok unit teszt, de pocsek elvi es tervezesi hibas, es ugy hatalmasra nott adatbazissal.

( Aadaam v | 2016. 12. 03., szo – 18:35 )

Kompletten nem hiszek a unit tesztekben, most is tudnék neked olyan kódot mutatni, ami sz.rrá van unittesztelve, szépen is néz ki, csak a követelményeket pottyantja telibe, meg ami nemvolt kiírva explicit a követelményekbe (hogy ne csússzon szét a UI) csak azt gondoltad, logikus, azt is.

Én se teljesen értem, én megírtam a user story-kat, néhol az acceptance criteria-kat is, szétszedtük az egész UI-t widgetekre, a teljes tervezés bootstrap grid felett zajlott, a design forrásfájlok elérhetőek, a widgetek működését leírtuk pszeudoalgoritmussal de nem azt csinálja.

Minden sprint előtt végigkattintgattuk a prototípusokat a fejlesztők előtt, elmondtuk, mi ez, miért kell, miért így kell.

UX-ként mégis mi a fenét tehettem még volna?

Biztos jók, a szükségességükről nem vagyok meggyőződve, évekig kódoltam gyakorlatilag hibamentesen nélkülük, amikor találtak valamit, akkor is általában a teszt kódja volt túlegyszerűsítve (tartalmazott valami feltételezést ami az új helyzetben nem volt már igaz), azt tudom hogy a rendszernek át kell mennie a usability teszteken, mert addig csak elméletileg megy.

Félre ne érts, nem f@sza gyerek voltam aki arrogánsan tuti volt a kódjában, csak egy lépéssel előbb történt az ellenőrzésük, sokkal egyszerűbb volt a konstruktív módszer (hogy tételesen bebizonyítom hogy szükséges és elégséges egy adott funkció),
mint hogy fantázáljak arról, milyen szélsőesetek törhetik meg.

Jobban ráállt az agyam, nah.

De ettől még divatból meg kísérletezésből meg mi van ha mégse úgy van, meg csapatszabályok betartása miatt írtam unit teszteket, át is nézettem őket mással, csak értelmüket nem láttam sokat a generatív tervezés mellett, nem is nagyon törtek.

És nyilván ma már nem tervezik a kódokat sehol, nem is foglalkozom programozással, hiába keresnék duplaennyit, mit érnénk vele ha egy 50 modulos rendszerből 5 modul meg lenne tervezve mert én írtam, de a többi 45 a mostanában szokásos "cleancode + teszt, jóleszaz" módszerrel lenne fejlesztve.

Többet érek ha a tervezési mániámat user story-k írásába fojtom, ez a kreatív programozás nem tud felizgatni, de hajrá annak aki élvezi.

2-3 évig futottak sok-sok módosítással amit már az utódaim csináltak, de futottak. Utána bezárták a céget, nem a kód miatt.

Természetesen ha kellett, írtam unit tesztet, külön kértem a QA-kat hogy legyen körülötte selenium alapú integrációs teszt, és peer review is volt mindig a kódjaimon (függetlenül attól, teszteltek voltak-e vagy sem).

Egyszerűen tervezett kódok voltak, ez ma már ilyen elveszett tudomány mint a maja építészet vagy tudomisén, voltak hozzá folyamatábrák és azok úgy voltak megrajzolva hogy ordítsanak róluk hibák; a folyamatábrán le volt ellenőrizve előre a viselkedés gráfelméleti módszerekkel, utána lettek begépelve.

Dijsktra anno azt írta a könyvében ahol a tervezett kódírást (amit ma már kompletten elfelejtettek, de nem is CodeGarage kategória) bemutatta, hogy "a tesztek alkalmasak hibák jelenlétének kimutatására és tökéletesen alkalmatlanok a hiányuk jelzésére".

Pöcsölős munka, ma már talán nem is tanítják, meg nagyon manuálissá és unalmassá teszi a programozást (nincs az az adrenalin ami a frontális, rögtön fejből gépelem az IDE-be programozásban általában a vonzerő), de működik.

( azbest | 2016. 12. 05., h – 01:46 )

Nagyon függ attól, hogy milyen termékről van szó. Egy szolgáltatás esetén, amiben sok réteg épül egymásra, alapból van némi elfogadható hiba, amit a kommunikáció fennakadása válthat ki. Szóval a nagy lefedettség elég gyenge lábakon áll. Ráadásul párhuzamosan több fejlesztés is futhat több csapat által. Nameg, szolgáltatás jellegű terméknél egyébként is folyamatos maintenance van. Szóval van ahol csiszolódik a kód, van ahol új bugok keletkeznek :)

( traktor | 2016. 12. 05., h – 09:37 )

Mar megint egy ertelmetlen dilemma. Kivancsi vagyok a szavzok kozul hanyan kezdenek a szemoldokuket rancolni, mikor a pizzarendeles kozben a diszpecser visszakerdez: inkabb normalisan megsussuk, vagy a tesztagyuras legyen jo?

Ez a hasonlat azért nem igazán jó, mert a való életben nem igazán tudsz venni megsütetlen és/vagy gyúratlan tésztájú pizzát.
Talán jobb hasonlat a mosógépeké. Normálisan összerakott, szerelhető, 20-30 évig üzemelő mosógépet szeretnél (pl. Miele) 200eFt-tól erősen felfelé vagy ugyanolyan tudású, de nem szerelhetőt, 3-7 évig üzemelőt 50eFt-tól.
Szerintem azt senki sem vitatja, hogy X idő alatt megírt kódhoz, ha készítünk 1-3X idő alatt teszteket és jobbá tesszük 1-3X idő alatt, akkor az jobb (legalábbis nem rosszabb), mint azok nélkül.
Ha határidő vagy büdzsé miatt csak 2X fejlesztési időnk van, akkor valamiből húznunk kell. Ilyenkor jön a dilemma.
Arról nem is beszélve, hogy rengeteg X idejű fejlesztést is láttam. Ilyenkor viszont nincs dilemma, mert egyikre sincs idő ;)

Nem te mész hozzájuk, hanem ők jönnek hozzád.
Ha még nem találkoztál ilyennel, nem is hallottál ilyenről és el sem tudod képzelni, akkor örülj neki!

Ez utóbbiakat azért nehezen tudom elképzelni, mert a Hup-on is sokszor jött elő ilyen, csak egy-két példa innen:

A management belemegy a megkérdezésed nélkül, mert biznyic, és abból jön a pénz, te pedig cseszheted, felül vagy bírálva

Kb. másfél év kellett, míg eljutottak odáig, hogy valami értelmes került a csapatba, aki rájött, hogy használhatatlan a kód és érdeklődni kezdett.

Néha kell prod szintre is gányt engedni, mert megtérül... szoktam mondani, hogy ha egy feature hoz két üzemeltetőnyi pénzt, cserébe elvisz egy üzemeltetőt az életben tartása, akkor ki fog menni élesbe, mert megtérül.

Vagy Tőled egy-kettő:

Mindig azzal kell dolgozni ami van es minden a kicsinel nagyobb projekt az "atvett" mert a kollegak fele mar reg nincs ott akik a kodot irtak. Az lehet kerdeses, hogy ebben az esetben neki kell-e allni az oncelu kodtisztitasnak (tehat nem bug javitas, funkcionalitas nem valtozik), vagy minden uj funkcio hozzaadasakor kell az erintett reszeket tisztabba tenni. Szerintem az utobbi.

A kódminőség javítása manapság sokkal fontosabb, mint az új funkciók. Optimalizálatlan, bugos kóddal lassú és sebezhető lesz a rendszer.
Erre a válaszod:
Te dolgoztal mar olyan projekten ahol az volt a feladat, hogy "ne valtozzon semmi, csak legyen jobb?" azaz, hogy nem kellenek uj funkciok, most csak a kodminoseget javitjuk fel evig?

"Ha még nem találkoztál ilyennel, nem is hallottál ilyenről és el sem tudod képzelni, akkor örülj neki!"

Jobban belegondolva igy van. Szerintem meg sosem voltam ilyen orult projektben, ahol felelotlen vallalasok ellehetetlenitettek a normalis munkat. Kezd az az erzesem lenni, hogy a szavazas a hulye kerdesre probalja megtalalni az ertelmes valaszt. Szeritnem ez nem fog menni.

1) egy szavazas nem valaszokat, hanem velemenyeket kerdez. A velemeny olyan, mint a segg, mindenkinek van, itt most erdeklodes tortenik, hogy kinek milyen.
2) Miert lenne hulye a kerdes? A vilagban nagyon sok olyan dolog van, amivel meg nem talalkoztal/talalkozhattal, viszont az azzal kapcsolatos kerdesek teljesen validak azok szamara, akik meg ismerik azokat a problemakat.
--
Blog | @hron84
Üzemeltető macik

( bri | 2016. 12. 05., h – 13:23 )

Kerdes, hogy mit fed le az a 10%. :-)

alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

( uid_17626 | 2016. 12. 06., k – 09:58 )

Nekem a TDD-vel az a bajom, hogy nem mindig szükséges. Vagyis valamiféle hibrid dologban gondolkodom és dolgozom. Osztályaim és függvényeim többnyire várt adattal dolgoznak, így nem okoz meglepetést az input, ami igen korlátos minden esetben és azt a pár verziót már tervezésnél lekezelem. Ahol viszont szükségesnek látom az a mások által küldött/kapott adat feldolgozása.

Mentségemre legyen mondva, hogy egyedül fejlesztek saját magamnak, de igyekszem alkalmazni a "nagyoknak" bevált praktikákat és módszereket. Valószínűleg egy nagyobb környezetben sokat változna a módszerem, de így egyedül jelenleg számomra ez kielégítő és hatékony.

( wachag | 2016. 12. 06., k – 17:33 )

Ezért vicces a digitális hardvertervezés, ott teszt és verifikáció nélkül szívás tud lenni a dolog. Jóval nagyobb a költsége, ha elbarmolsz valamit. Illetve a vacak kóddal sem jutsz messzire.

Amúgy a >90% coverage unit test - ha jól sejtem - egész rendszernél semmit nem jelent.

( zoli78 | 2016. 12. 09., p – 22:17 )

Ennek a szavazásnak mi az értelme? Nem válaszolhatom azt, amit gondolok. A két lehetséges válasz közül egyik se az, amit válaszolnék. A kérdés feltevése implicit tartalmazza azt, hogy vagy jó minőségű a kód kevés teszttel vagy szar a kód, de túlzottan is le van fedve unit tesztekkel (ami megint nem jó, túl merevvé teszi a tesztkörnyezetet).
Úgy se tudom értelmezni, hogy a plusz időt mire szánnánk, mert a jól tesztelt és jó minőségű kód esetén kevesebb az utólagos szívás ha bele kell nyúlni, illetve kevesebb időt kell hibakeresésre fordítani a minőségi tesztelés miatt. Emiatt a legolcsóbb megoldás az, ha a kódminőség és a megfelelő unit tesztek is megvannak. Meg amúgy is ha eleve jó minőségben készülnek a tesztek a kódolás közben, akkor már a legegyszerűbb a clean kód elveit betartani a kód írása közben is, így gyakorlatilag a kettő együtt jár.
Kb mintha azt kérdeznék hogy előbb gyomor vagy fej...

Talán az lehet a gond, hogy nem fejtettem ki expliciten, hogy mit is értek jó minőségű kódon, bár ez a szavazás magyarázatánál (első hozzászólás) valamelyest kiderül.

Jó minőségű kód alatt ezen szavazás alatt azt értem, hogy nem csak egyszer megírod a legjobb tudásod és clean code meg hasonló elvek alapján, hanem még legalább ugyanannyi időt (kb. annyit, mint a hozzávaló unit tesztekre is fordítanál) a kódod javítására fordítasz vagy fordítotok (code review, páros programozás, ...).

Tehát így is gondolkodhatsz a szavazásnál:
- ha a kód X idejű írásán túl X időt a jobbítására és X időt a unit tesztekre fordítasz, akkor ha csak 2X időd van, akkor inkább melyiket csinálod meg.

Ha nem tudsz dönteni, mert pl. a kód X idejű írásán túl, 1/2X időt a jobbítására és 1/2X időt a fele kódod unit tesztelésére (vagy az összes kód félig tesztelésére?) fordítanád, akkor ne szavazz (vagy csak ez eredmény érdekel) és fejtsd ki hozzászólásban.

túlzottan is le van fedve unit tesztekkel (ami megint nem jó, túl merevvé teszi a tesztkörnyezetet).

Ilyen véleménnyel még nem igen találkoztam. Eddig ezzel a három csoporttal találkoztam:
- Minden kódra kell unit tesztet írni (pl. TDD-sek)
- A legtöbb kódra kell, esetleg a triviálisokra nem (generált getter/setter)
- Nem igazán kell, esetleg a fontosabbakra, bonyolultabbakra vagy refaktorálandókra.

Leírnád, hogy pontosan mit is értesz a fentiek alatt? Mi a túlzott lefedés? A sok unit teszt milyen értelemben teszi merevvé a tesztkörnyezetet?