Soci blog

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.

Forrás.

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:

• 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.