Category Archives: Testing

TDD is dead. Tényleg?

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. :)

Test Driven Development – I like it

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.

64 bites Office 2010 és unit tesztek

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. :)

Edit and Continue – hasznos-e?

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? :)

Mocks Aren’t Stubs

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:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Érdemes rászánni tíz percet, tudattágító hatású cikk.