Test Driven Development (TDD) is often reduced to the three phases
There is nothing wrong about these three steps. But there is more involved in test-driving your development.
Dani and me have started to keep a list of software development and presentation skills related books that we have read.
Check it out here.
When I talk with fellow developers new to Scrum, I often hear a fundamental misunderstanding about Sprints. These colleagues are normally used to Waterfall or RUP methodologies. As a consequence, they think of Sprints as very short repetitions of the following phases: requirements (planning meeting), design, implementation, test (sprint review as acceptance).
And this is completely wrong!
Let me tell you why.
I found a promising community on agile software development created by Kelly Waters.
If you are interested in agile development then check it out (click on banner):
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:
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:
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>