Updated: Something went wrong with the code snippets. Now it’s okay.
Today, we”l have a look at nested views in my series on agile UI development in .NET using an extended MVVM pattern (table of contents).
There are two kinds of nested views:
We got the following geek question from Henrik:
Hi, Thanks for sharing this preview of the MockStyle.Stub feature! Its exactly was I was looking for when I googled this page, so now I just can't wait for a release with this includedI tried to find some information on futre release plans but could not find any. Could anybody help me out? When could we3 expect a new NUnit supporting MockStyle.Stub? Cheers! Henrik
The answer to this question is a bit complicated. Let me tell you why:
The current development team of NMock2 (Thomas, Peter and me) will not actively continue to develop NMock2. We’ll still provide basic support (bug fixes) but no new features. However, we have planned to make one last release (including the Stub feature) when we are sure that it works in our projects. This will be soon because we didn’t have a new defect in the last two months or so.
The reason why we have lost interest is that Moq has gained a lot of momentum and has a much broader community support. Furthermore, Moq provides some basic improvements that we cannot simply add to NMock2: besides the type safe, refactoring friendlier syntax, it allows very clean AAA (Arrange, Act, Assert) unit tests.
On the other side, there exists the NMock3 project on CodePlex that adds a type-safe syntax wrapper around NMock2. Check it out, when you already use NMock2 in your project.
So for short: the release including the Stub feature will be available soon, but it will also be the last release.
If you can’t wait until the official release then get the code from the subversion repository and start the build.release.cmd, et voila!
Happy mocking (whatever framework you use)
Urs
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:
I always wanted to get my hands dirty with a little expression tree magic but never had the time to do so. When test driving code of a component you are currently working on you might feel in the middle of the “Do a little change, let it fail, make it green” process that your component needs an event which is publicly visible and can be subscribed by clients. But how would you test that the event is fired on your component’s interface? I’ll show you how this is normally achieved and how an event tester could simplify the process.
In this post, we are going to have a look at UI commands. UI commands are responsible for reacting to user input, for example the send button click in the sample I use throughout this series of agile user interface development in .NET series. For other posts in this series look here: table of contents.
We have seen in the last post that the view binds a command to the send button that it gets from the view-model:
<Button Command="{Binding SendMessageCommand}" IsDefault="True">Send</Button>