Jövő januárban újra lesz TDD tanfolyam, most ősszel már nem volt időm betervezni egyet.
Aki december 1-ig jelentkezik, azt most 150e-ért csatlakozhat.
Jövő januárban újra lesz TDD tanfolyam, most ősszel már nem volt időm betervezni egyet.
Aki december 1-ig jelentkezik, azt most 150e-ért csatlakozhat.
Tolom a teszteket ezerrel (ATS-elek), ez a kis snippet jól jött.
Pont TDD tanfolyam volt előző héten, amikor volt egy videó, amiben David Heinemeier Hansson, Martin Fowler és Kent Back beszéltek (vitatkoztak?) a témáról. A kiváltó cikk ez.
A második két ember gondolom közismert, David Heinemeier Hansson a Ruby on Rails létrehozója.
Az első rész nem volt túl mély, remélem a másodikban kicsit jobban belejönnek, bár lehet, hogy kár ezt várni. Van, amikor természetesen jön a TDD, van, amikor nem, ilyenkor igyekszünk utólag tesztelni, ha sikerül. Semmi se szentírás a szakmában, van, aki elölről szereti, van, aki hátulról. Mint az Eurovíziós dalfesztiválon. :)
Egyre több dolgot TDD módon írok meg. Ami szembetűnő a korábbi, először implementálok aztán ha van rá idő írok hozzá tesztet (nem fogok) módszerhez az a következő:
-Sokkal kevesebbet, nagyon sokszor egyáltalán nem debugolok. Ez eszement sok időt spóroló tevékenység, gyűlölöm, amikor 2-3 percet is nyomkodok, mire eljutok a betegnek vélt ponthoz a debuggerben. Ott aztán sokszor kilép a debugger (pont timeoutolt a web worker process), release kód miatt nem mutat változókat, továbbléptetem, aztán kezdhetem elölről (lehet mozgatni a current pointert, de ha már okoztunk mellékhatásokat hiába megyünk vissza), stb. Szeretem az advanced debuggung témát, de utálom az időt vele feleslegesen tölteni.
-A GUI-t alig indítom el, ezáltal megint nagyon sok időt takarítok meg.
-Az implementált dolgaim azonnal mennek, amikor a GUI-t is elindítom, már csak élvezni kell az eredményt.
-Hamarabb készen vagyok a feladattal. Tudom, ezt nem lehet objektíven mérni, mert nincs mihez viszonyítani. De az első két pont miatt érzésre annyi időt megtakarítunk, ami felülmúlja a tesztekre szánt időt.
Igazából a TDD nem is a tesztelésről szól. Ez komplexitás és félelem kezelés. Arról szól, hogyan implementáljuk egy bonyolult feladatot sok kicsit változaton keresztül úgy, hogy ne őrüljünk bele, ne legyen sok kudarcunk. Az már csak egy plusz, hogy sokkal jobb lesz a kódminőség.
A VS coverage-e ezt mutatja, hogy ez a sor csak részben van lefedve:
return (GetSourceItem(step) – this[step – 1]) * e + this[step – 1];
Nincs benne && vagy ||, akkor triviális lenne. Én már tudom a választ. :)
Update: alul, kommentben ott a megoldás.
Futtatni akartam pár régebbi unit tesztemet, de nem mentek, azt mondta, nem találja a Microsoft.ACE.OLEDB drivert. Tévesen több helyen azt láttam, hogy azt kell beírni, hogy Microsoft.ACE.OLEDB.14.0, de nem, a registryben is a régi, 12-es verzió van. Megnéztem, az InprocServer32 a C:\Program Files\Common Files\Microsoft Shared\OFFICE14\ACEOLEDB.DLL-re mutat, ami a manifestje alapján 64 bites C runtime dlleket használ, szóval tényleg van 64 bites access driver. (Az InprocServer32 név jó nagy fiaskó, minden ilyen bedrótozott verzió visszaüt később, mint a 16 bites shortParam, ami valójában 32 bites int).
Sejtettem, hogy 64 bit – 32 bit probléma van, de nem jöttem rá mi az oka, míg a tesztben ki nem írattam a teszt futtató bitszámát: Environment.Is64BitProcess == false.
Ekkor csaptam a homlokomra, hogy alapban 64 bites gépen is 32 bites processzben futnak a tesztek. De szerencsére át lehet állítani.
Ti ne töltsetek el 1 órát ilyen marhasággal, emlékezzetek erre. :)
Vistában már lehetséges, egyes programok tesztelésénél jól jöhet.
Elsősorban a teszthez szükséges bemenő cuccokat lehet ide másoltatni a TestContext.AddResultFile(“filename”); segítségével.
Architektúra kedvelőknek egy jó kis cikk a Supervising Controller pattern használatáról ASP.NET-ben.
Annak idején, még a VS 2005 illetve a .NET fw. 2.0 tervezésekor szó volt róla, hogy a C#-ban lesz refactoring (ez ugye csak VS fícsör), a VB-ben nem. Cserébe a VB-ben lesz Edit and Continue, de a C# nem kap ilyet.
Akkor az volt az érv, hogy a C#-osok komoly emberek, akik naphosszat refactorolnak, de nem hekkelnek a debugolás alatt álló kódon, mert az gagyi. De aztán a C# lobbi belerakatta.
Most, hogy C++-ban dolgozok, ahol már a VC6 óra van E&C elég sokat használom. Azért, mert gyakran van, hogy valami apróságot elszúrok, és mire azt a kódot újrafuttatom, sok időt veszítenék. Egyébként egy IE addont írok. Tudom, ha lennének jó Unit tesztjeim, akkor pikk-pakk újra lehetne futtatni a kódot a vizsgált pontig, de nincsenek, C++-ban még nem értek a Unit teszteléshez.
Szóval értem az érvet, komoly, unit tesztekkel felvértezett programoló nem használja az EC-t, de én úgy látszik nem vagyok az, így örülök neki, hogy van.
Amikor év elején egy C# kódot gyúrtam át, akkor nem is emlékszek, hogy használtam volna, de ott volt valag sok unit tesztem.
Ti használjátok, vagy komoly programolók vagytok? :)
Martin Fowler bátyó szokás szerint éleslátóan ír, ezúttal a különböző Unit tesztelési módszereket elemzi ki.
Rá kellett jöjjek a cikk alapján, hogy a DP tanfolyamon Mockként tanított objektumok valójában Fake objektumok voltak. Mert hogy:
Érdemes rászánni tíz percet, tudattágító hatású cikk.