In the last couple of weeks, I ran over some posts about c# coding style guidelines, i.e. guidelines about how to arrange (style) your code. This normally includes things like where to put paranthesis, how fields are named (e.g. with/without _) and so on.
All these posts (no I don’t have the links anymore) had two things in common: 
I must say I’m really a huge fan of Moq. Moq is steady growing and the developer community is quite impressive in inventing new features and extensions. I recently ran over a nice feature suggestion placed in a private branch from moq. The branch belongs to Brian J. Cardiff. I suggest you check also his blog out! The feature brain suggested is an extension method which allows to do sequential setups. The sequential setup allows to specify in a fluent way for example different return types on a mock for each call. Let’s have an example!
The first post of this series gave a quick overview over the event tester usage, the last post gave a deep dive into some part of the event tester code. When talking about line numbers or certain code expression I’m always referring to the code provided in the last post.
When talking about the expression tree construction in the last post the last thing we got into was the build up of the if/then/else expression. After building up the if/then/else expression we need to build the expression code which calls the if/then/else expression by passing in the parameter array which we built up with the GetParameterExpressionsFor method.
In my last post I gave a quick overview over the event tester usage and how you could benefit from such a component. In this post I want to show you the source code of my event tester implementation and give you a short dive into the expression tree magic that is happening behind the scenes. This time I show you first not only portions of the code but the whole code in advance annotated with line numbers. My explanations will point to line numbers in the code below.
In my series on agile UI development in .NET, we have seen quite a lot so far (table of contents). But up to now, we never made a call to the model (business logic, services and so on). This is the topic of this post: Model Commands.
A Model Command encapsulates a single action hat is execute against the model. This can be a query to request data, an action that modifies data, communication with a completely different part of the system or anything else your application has to do on the model.
Next in my series (table of contents) on agile UI development in .NET is the presenter. The presenter is responsible to drive the UI workflow. This means that the presenter is the control center to react to: