-
Statically-typed reflection with LINQ
-
Quite some time ago I posted about how to use LINQ to provide a strong-typed reflection API. I used a very old LINQ preview back then.
With .NET 3.5 and C# 3.0 released now, it was time for an update. As part of the update, I also improved the API a little bit. Usage now is:
MethodInfo toString = Reflect<object>.GetMethod(x => x.ToString());
The renamed Reflect<TTarget> class receives the type you want to reflect as a generic parameter. Then you can use GetMethod, GetField or GetProperty...
Read full article
-
Mocks: by-the-book vs practical
-
Lately, there's been some formalization of the definitions of mocks, stubs, fakes and dummies, which Fowler popularized through his site with his article Mocks aren't Stubs by introducing the concepts from Gerard Meszaros' xUnit patterns book. I haven't read the book, but the definitions are sensible.
The article attempts to clarify the Mock and Stub concepts, while trying to separate them from the testing styles known as mockist TDD and state/classic TDD. In my opinion, the article fails because the very concept of a Mock is quite different in the mind of one or the other kind of TDDer. ...
Read full article
-
NavigationWindow, WinFormsHost and TextBoxes: backspace bug
-
WPF NavigationWindow is a very handy class that allows you to easily build Vista-like wizards, or any kind of window that resembles the browser-style navigation:
The NavigationWindow will automatically handle the Backspace, Back/Next keys and perform the appropriate navigation on the window pages.
If you're combining this class with the WindowsFormsHost to integrate WinForms controls, you may hit a very annoying bug: if there are textboxes in your WinForm control, hitting Backspace while editing the input on it will cause the navigation window to navigate back, instead of deleting the text on the TextBox. Yikes! ...
Read full article
-
What's wrong with the Record/Reply/Verify model for mocking frameworks
-
Most mocking frameworks, and especially the two most popular ones, Rhino Mocks and TypeMock, use a record/reply/verify model where the developer invokes members on the mock during the record phase, does a replay to prepare the mock for those expectations, and finally do a verify before the test ends.
From Rhino documentation (emphasis mine):
Record & Replay model - a model that allows for recording actions on a mock object and then replaying and verifying them. All mocking frameworks uses this model...
Read full article
-
State Testing vs Interaction Testing
-
Highly recommended reading: Fowler's article Mocks aren't Stubs. It's a very clear characterization of the types of so-called Test Doubles (mocks, fakes, stubs, etc.) you can use to aid your unit testing needs, but also of the kinds of TDD you can do: classic (or state) TDD and mockist (or interaction) TDD.
I got the feeling that the article seemed a bit biased towards mockist TDD, only to see in the "So should I be a classicist or a mockist?" section that Fowler himself is a classic TDDer :o). Maybe it's because mockist TDD is a newer approach to TDD and therefore required a more extensive explanation. Or maybe it's just that the article title is a bit misleading as its content is about mocks in the strict sense used by mockists, and not in the general sense I think of them (as generic aids in unit testing)....
Read full article
-
Mocks, Stubs and Fakes: it's a continuum
-
Highly recommended reading: Fowler's article Mocks aren't Stubs.
Generically called (by Gerard Meszaros's xUnit patterns book) Test Doubles, all three kinds of test aids are intended to replace real implementations of dependencies of the object under test. From Fowler's article, we learn the difference between them as explained by Meszaros:
- 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 ...
Read full article
-
Linq to Mock: MoQ is born
-
Regardless of whether you use a mocking framework/library or not, as long as you're doing unit testing, you're almost for sure using mocks. Most of the time they are manual mocks typically not even shared outside the scope of a single test fixture as they contain hardcoded values for return types, helper members, etc.
This works well, but it's counter-productive and plain boring. Mocking interfaces just to implement the one or two members you're interested sucks. ...
Read full article